Was wünscht ihr euch für C# 5?

Tja, ich wünsch mir nur ein: Endlich mit .NET im Kernel Mode entwickeln. Bleibt aber bis wahrscheinlich Windows 10 undenkbar 😃

Ja, aber dann kann man das .net framework nedmehr uneingeschränkt verwenden und man bräucht inline-assembler

Jepp, das ist richtig. Da .NET früher oder später ein noch wesentlicher Bestandteil des OS sein wird, ist es glaube ich nur eine Frage der Zeit. Mit Windows 8 soll ja die Barriere .NET und Shell endlich gebrochen werden (Shell Extensions). Das wird der erste große Schritt sein Richtung Kernel Mode.

Und Inline-Assembler würde ich zudem extrem genial finden.

public assembler void DoSomething()
{
  codeseg
  {
    mov ax,34Fh;
    // usw...
  }
}

Ach, ein Traum...

Nochmal zum eigentlichen Thema:
Momentan vermisse ich in .NET bzw. C# eigentlich nichts. Bisschen syntaktischer Zucker hier und da vielleicht, aber wirklich bahnbrechende Änderung würde ich jetzt nicht benötigen.

Ich würde mir gerne 'const' bei Methoden und Parametern wünschen (so wie in C++), d.h. daß man nicht einfach Änderungen vornehmen kann, nur weil man gerade eine Referenz auf ein Objekt erhalten hat.

Jepp, das ist richtig. Da .NET früher oder später ein noch wesentlicher Bestandteil des OS sein wird

das glaube ich kaum. Den Versuch, mit Windows Longhorn die Shell etc in .NET zu machen, hat MS teuer bezahlt. Den Fehler machen sie kaum ein 2. Mal.

Ich bin der Meinung, das MS das machen muss. Es ist halt definitiv nicht möglich Shell Extensions in .NET zu schreiben, ohne Gefahr zu laufen, das man das System komplett zerstört. Und IMHO ist es zwingend erforderlich, das MS diesen Schritt macht, da sie damit einige Entwickler "aussperren" (ist jetzt überspitzt formuliert). Aber das das kommt steht ja schon definitiv fest. Nur wann halt nicht 😉

Wie MS das jetzt zum Schluss realisiert, ist mir eigentlich wurscht. Hauptsache es geht hinterher. Ob die jetzt den Kernel umbiegen, damit das .NET FW noch eher gestartet wird, oder die Shell umgebogen wird, oder der Explorer gar komplett selber in .NET daher kommt (da könnt ich MS sicher ein bisschen helfen 😃). Man weis es nicht.

Den Fehler machen sie kaum ein 2. Mal.

Spielst du auf WinFS an, oder was genau meinst du?

mov ax,34Fh;  

Sowas nicht unbedingt. Ich würde für .net register wie zB nax nehmen, die beim kompilieren auf die richtige Plattform angepasst werden. Also wenn man 32bit kompiliert eax, bei 64bit rax. Das fände ich besser.

Gruß pdelvo

Lol: Plattformunabhängige Kernelkomponenten^^

Ich weiß nicht ob VS2010 das bereits mitbringt, da ich mit damit erst beschäftige wenn's wirklich raus ist, aber ich wünsche mir schon seit geraumer Zeit dass generische Typen in Typen gecastet werden können welche einen Basistypen das aktuellen Typen darstellen:

List<TextBox> textBoxes = new List<TextBox> { new TextBox() };
// Geht bis 2008 nicht:
List<Control> controls = textBoxes;

Ich arbeite viel an Basis-Libraries und habe mit sowas oft Probleme.

Hi Florian,

das wird mit C# 4 gehen. Nennt sich Kovarianz beziehungsweise Kontravarianz von generischen Typen.

Viele Grüße,

Golo

Friend Klassen wären auch ein ganz nettes Feature. Schön wäre auch wenn C# bzw. .NET endlich mal in der Geschwindigkeit mit nativen Anwendungen konkurrieren könnte.

Hallo Golo,

Nennt sich Kovarianz beziehungsweise Kontravarianz von generischen Typen.

Kennst du den Grund warum es das bisher nicht gab? Technisch sollte es ja machbar gewesen sein.

mfG Gü

Hallo Golo

Super! Danke für die Info!!

Dann bin ich im Augenblick wohl wunschlos glücklich wenn ich auf VS2010 umsteige und schließe mich gfoidl's erstem Post an, wenn mich mal wieder was ärgert gebe ich Bescheid was mir fehlt =)

Schönen Abend noch
Flo

Friend Klassen wären auch ein ganz nettes Feature.

Was meinst du damit? Geht das nicht mit dem internal Modifizierer?

mfG Gü

Bin ich dagegen. Wenn man Zugriff auf die Private/Protected Elemente einer anderen Klasse benötigt, zeugt das meiner Meinung nach von schlechtem Design.

Kommen Vererbung und Friends nicht aufs gleiche hinaus?

Kennst du den Grund warum es das bisher nicht gab? Technisch sollte es ja machbar gewesen sein.

Liegt daran, dass die Generischen Typen nicht abgeleitet sind. List<TextBox> wird direkt als eigener Typ erzeugt und nicht von einem (nicht vorhandenen) Typen List<Control>, List<Component> oder List<IDisposable> abgeleitet. Das zeigt auch schon das technische Problem des Compilers. Soll List<TextBox> jetzt von List<Control> oder List<IDisposable> abgeleitet...?

Bin aber echt froh, dass es mit 4.0 intern(!) irgendwie hingefrickelt wird 8)

Friend Klassen wären auch ein ganz nettes Feature.
Was meinst du damit? Geht das nicht mit dem internal Modifizierer?

Mit dem internal Modifizierer können alle Klassen aus der Assembly auf die entsprechenden Member zugreifen, wobei man mit dem friend Modifizierer AFAIK genau definieren kann welche Klasse den Zugriff hat.

Bin ich dagegen. Wenn man Zugriff auf die Private/Protected Elemente einer anderen Klasse benötigt, zeugt das meiner Meinung nach von schlechtem Design.

Wäre aber IMO ideal um das Prinzip der einzigen Verantwortung mit der Datenkapselung zu verbinden. So könnte man z.B. beim Serialisieren auch private Member mit-serialisieren, was ab und zu nötig ist.

Gruss

Liegt daran, dass die Generischen Typen nicht abgeleitet sind.

Das stimmt. Allerdings wird für Referenztypen (und nur da ist Ableitung vorhanden) einmal der (geJITete) Code generiert der dann für alle Referentypen des generischen Typs verwendet wird.

Insofern gilt dass List<T> where T : class für List<TextBox>, List<object>, List<IDisposable> den selben Code verwenden. Somit würde ich sagen dass zB List<T> where T : class von List<object> erbt - der Cast sollte also möglich sein (auch wenn das Ergebnis null wird wenn die Typen in der Vererbungshierarchie nicht passen).

mfG Gü

Hi Gü

Liegt daran, dass die Generischen Typen nicht abgeleitet sind.
Das stimmt. Allerdings wird für Referenztypen (und nur da ist Ableitung vorhanden) einmal der (geJITete) Code generiert der dann für alle Referentypen des generischen Typs verwendet wird.

Insofern gilt dass List<T> where T : class für List<TextBox>, List<object>, List<IDisposable> den selben Code verwenden. Somit würde ich sagen dass zB List<T> where T : class von List<object> erbt - der Cast sollte also möglich sein (auch wenn das Ergebnis null wird wenn die Typen in der Vererbungshierarchie nicht passen).

Hast auch wieder recht. Naja, Hauptsache sie haben's jetzt hinbekommen. Das hat mir echt schon oft Kopfzerbrechen bereitet.

Danke Dir
Flo

Wäre aber IMO ideal um das Prinzip der einzigen Verantwortung mit der Datenkapselung zu verbinden. So könnte man z.B. beim Serialisieren auch private Member mit-serialisieren, was ab und zu nötig ist.

Sehe ich nicht so. Ich würde eher die serialisierung über ein Interface in die Klasse selbst verlegen, sodass es von der Klasse selbst übernommen wird. Nur die Speicherung wird außerhalb erledigt.

Bei mir kennen die zu Cachenden Objekte eine ICacheEngine, die Speicherungsmethoden hat. Somit werden die Objekte automatisch gechached, wenn sich Daten ändern (was bei diesen Objekten nur von außen passiert, d.h. außer neue Daten werden reingefüttert bleibt das Objekt gleich).

Liegt daran, dass die Generischen Typen nicht abgeleitet sind.

Ist IMHO nicht der Grund - der Grund ist eher, dass die Typsicherheit verletzt werden könnte und Probleme entstehen könnten, die erst zur Laufzeit auftreten. Als simpler Beispielcode:

List<string> myStrings = new List<string>();
List<object> myObjects = (List<object>)myStrings;
myObjects.Add(new object());

Dabei knallt's dann (zur Laufzeit), weil die zu Grunde liegende Liste eben nur Strings aufnehmen kann, und ein object kein String ist.

Bei C# 4 gibt es die neuen Schlüsselwörter in und out, mit denen man dieses Verhalten explizit freigeben muss - das heißt, es geht nicht OOTB per se mit jeder Collection. Der Sinn der expliziten Freigabe liegt eben genau darin, dass der Entwickler wissen soll, welche Gefahren er sich einhandelt.

mov ax,34Fh;  

Sowas nicht unbedingt. Ich würde für .net register wie zB nax nehmen, die beim kompilieren auf die richtige Plattform angepasst werden. Also wenn man 32bit kompiliert eax, bei 64bit rax. Das fände ich besser.

Hallo,

ich kann verstehen wie man auf die Idee kommt, plattformunabhängige Register haben zu wollen, halte es aber für wenig sinnvoll. Das Programmieren in Assembler lebt ja gerade davon zu wissen wie groß die Register sind um diese optimal auszunutzen. Desweiteren würde so ein plattformunabhängiges Register auch technisch nicht funktionieren. Nehmen wir an wir weisen dem Register eine 32 Bit Zahl zu. Auf 32 Bit Systemen tut alles wie normal, auf 64 Bit Systemen wird die 32 Bit Zahl in ein 64 Bit Register geschoben und die restlichen 32 Bit die man eventuell ausnutzen könnte, würden brach liegen. Man entzieht dem Assembler ein wenig seiner Möglichkeiten. Wenn man mit einer 64 Bit Zahl arbeiten würde würde die auf nem 64 Bit System gut reinpassen, auf nem 32 Bit System dagegen wieder gar nicht. Und da steht man nun vor dem Problem festlegen zu müssen wie breit das Register ist. Und damit ist man wieder am Anfang mit seinen speziellen 32 und 64 Bit Registern und man hätte durch so ein allgemeines Register nichts gewonnen.

Hallo,

ich halte vom "plattformabhängigen Assembler in C#" rein gar nichts. Wenn jemand das haben will dann hat er mit C# einfach die falsche Sprache. Dafür gibt es C++ (und andere).

C# läuft als .net in einer isolierte virtuellen Umgebung - der CLR - und daher wäre es schon ein grobes verbiegen dieses Konzepts wenn dadurch die Isolation durchbrochen werden.

Sorry, aber so einfach sehe ich das.

mfG Gü

Mit plattformunabhängig meine ich, dass beim kompilieren festgelegt wird, ob es eine 32 oder 64bit anwendung wird. so gibt es verschiedene register, die in einer größer kleiner beziehung steht, so ist uB das register nax > max oder so. Dann wäre bei 64bit nax rax und max eax, bei 32bit nax eax und max ax. Sonst sind die Vorteile von C# vollkommen verspielt.

Trotzdem kann ich deine Ansicht verstehen. Ich würde trotzdem diese möglichkeit bieten. Natürlich ist das nicht immer sinnvoll, aber es gibt anwendungsfälle, in denen man die plattformunabhängigkeit von c# und die Vorteile, des direkten Assemblers kombinieren möchte. Für solche Situationen finde ich solch eine Lösung sinnvoll.

@gfoidl: Natürlich wird man C++ nicht verdrengen können. Es ist schon seit langem Etabliert und für unmanaged Bereiche gedacht. Trotzdem wäre es spannend seine C# Anwendung ohne OS laufen zu haben. Da gibt es zB schon das Projekt Cosmos, welches il in maschinencode übersetzt und so programme bootbar zu machen. Schöner wäre es aber sowas in dem Compiler schon vorzufinden. Soweit meine Meinung.

Gruß pdelvo

Hallo zusammen,

ich wünsche mir für C# 5.0, dass die Technologie-Schwämme gestoppt wird! Statt dauernd neue Technologien auf den Markt zu werfen, sollte sich Microsoft lieber auf Qualität zurück besinnen und erst mal die Fehler in den aktuellen Technologien des .NET Frameworks beheben.

Das Zeug wird momentan schon wieder als veraltet erklärt, bevor es halbwegs ausgereift ist. Bestes Beispiel dafür ist die Workflow Foundation.

Zitat von: Golo Roden

• Statische Member und Konstruktoren in Interfaces

Sowas hatte ich mir auch schon gewünscht, geht aber meiner Meinung nach auch mehr Richtung Klassentemplate.

• Parametrisierbare Properties

Naja, Properties sind letzendlich Verkürzungen (Vereinfachungen) für Getter und Setter Methoden, die im kompilierten Code ohnehin dazu verwandelt werden.
Ich finde, noch leichter brauch man es doch nicht zu haben. Dann schreibt man eben klassische Getter und Setter.

Mehrere Vorfahren bei der Vererbung wären eine schöne Vereinfachung. Alternativ könnten es auch Interfaces sein, die Code akzeptieren.

Interfaces sollten auch das Schlüsselwort protected zulassen.

Erwärmen könnte ich mich auch für die aus PHP bekannten Magic-Functions __get und __set.

Hallo hinrich,

ich halte deine Änderungswünsche nicht für sinnvoll.

Mehrere Vorfahren bei der Vererbung wären eine schöne Vereinfachung.

Mehrfachvererbung wird in C# aus guten Gründen nicht unterstützt.

Alternativ könnten es auch Interfaces sein, die Code akzeptieren.

Gerade das ist ja nicht der Sinn von Interfaces! Dafür gibt es abstrakte Basisklassen.

m0rius

Hallo hinrich

Auch für protected kannst du abstrakte Klassen benutzen.
Interfaces sind ja eben öffentliche Schnittstellen und nützen dir gar nichts mehr, wenn du die Member nicht öffentlich hast.

Grus Peter

ich halte deine Änderungswünsche nicht für sinnvoll.

Schade.

Mehrfachvererbung wird in C# aus guten Gründen nicht unterstützt.

...

Gerade das ist ja nicht der Sinn von Interfaces! Dafür gibt es abstrakte Basisklassen.

Das ist absurd. Wenn es keine mehrfachen Vorfahren gibt, dann kann man nur eine abstrakte Klasse wählen. Das führt dazu, dass entweder triviale Source-Codes mehrfach implementiert werden müssen, oder aber man sich mit einem Wust an Satelliten-Klassen rumschlagen muss.

Und da mehrere Interfaces genutzt werden können, ist es für mich nicht wirklich einsichtig, warum das bei Klassen aus guten Gründen nicht unterstützt wird.

Hinrich

Auch für protected kannst du abstrakte Klassen benutzen.
Interfaces sind ja eben öffentliche Schnittstellen und nützen dir gar nichts mehr, wenn du die Member nicht öffentlich hast.

Abstrakte Klassen kann ich aber nicht mehrfach vererben (s. o.). Es kann aber sinnvoll sein, dass ein Interface geschützte Methoden vorschreibt, so dass beim Vorhandensein einer bestimmten Schnittstelle auch eine bestimmte geschützte Methode oder Eigenschaft existiert, die aber eben nicht öffentlich sein soll.

Hinrich

mfG Gü

Zum Thema: ich wünsche mir dass es überhaupt keine Version 5 gibt oder zumindest erst in 10 Jahren oder so. Ist ja ein Unding, dass man mehrere .NET Framework Versionen auf dem Rechner unterhalten muss, geschweige denn immer wieder für teures Geld VS neu anschaffen muss.

ich wünsche mir dass es überhaupt keine Version 5 gibt oder zumindest erst in 10 Jahren oder so. Ist ja ein Unding,

Ist ein sehr berechtigter Wunsch. Bei der Menge an neuer Technologie geht sehr viel Zeit drauf wenn man am Ball bleiben will - nebenbei sollte man noch der eigentlichen Arbeit nachgehen und das Leben beseht nicht nur daraus.

mfG Gü

Hallo,

naja, ich finde das in .Net eigentlich relativ geschickt gelöst. Es gibt im Prinzip nur 2 Runtimes die von Interesse sind. Die 1.1 und die 2er. Der Rest sind Bibliotheken die mit neuen Frameworkversionen kamen. Für den Enduser mag es zwar nicht immer einsichtig sein, aber im Prinzip brauch er nur .Net 3.5 und gut ist, da auch 1.1 Programme von wenigen Ausnahmen abgesehen ja gut laufen. Bei Java kommen auch laufend Updates raus wo ich die Run.time neu installieren muss. Da ist das noch viel schlimmer find ich.

Es stimmt natürlich das in .Net manche Technologien für tot erklärt wurden bevor sie überhaupt richtig erschienen sind. Da kann man leicht ins Zweifeln kommen ob man auf das richtige Pferd setzt.

Aber was ich auch überhaupt nicht einsehen kann sind so langsame Entwicklungszyklen wie bei C++ z.B. Da wird nicht in Jahren sondern in Jahrzenten gerechnet und 3rd Party Bibliotheken müssen ausgleichen was der Sprachstandard nicht bietet an Basisfunktionalität. Problem ist nur dass man für ein Problemgebiet zig Bibliotheken zur Auswahl hat die sich alle unterscheiden konzeptionell und man dadurch auch keine leichte Wahl hat, was man nun nutzen will.

Auch Java EE hat sehr lange Releasezyklen (wenn ich mir EJBs angucke), das finde ich dort auch nicht unbedingt vorteilhaft.

Klar haben kurze Releasezyklen den "Nachteil", dass man ständig neues lernen muss, auf der anderen Seite etablieren sich ungünstige Pattern erst gar nicht ...

mfG Gü

Ich wünsch mir dass AOP zumindest in der IDE standardmäßig möglich ist, ob das dann auch mit C# Spec 5 zu tun haben muss, ist eine andere Frage.

Wäre schön wenn alles was mit Postsharp möglich ist, dann auch so oder auf ähnliche Weise mit der VS xx IDE möglich wäre...

Ich wünsch mir dass AOP zumindest in der IDE standardmäßig möglich ist, ob das dann auch mit C# Spec 5 zu tun haben muss, ist eine andere Frage.

Wäre schön wenn alles was mit Postsharp möglich ist, dann auch so oder auf ähnliche Weise mit der VS xx IDE möglich wäre...

Oh ja! FULLACK

Kurze offtopic Frage: Golo, machst Du denn etwas mit AOP, ich meine beruflich momentan?

Hallo zusammen

Oh ja! FULLACK

Da schliesse ich mich an!

Gruss Peter

Hallo hinrich,

entschuldige, ich habe dich falsch verstanden.
Ich habe gegen eine prinzipielle Einführung der Mehrfachvererbung argumentiert; ich stimme dir allerdings in der Hinsicht zu, dass diese manchmal gerade bei abstrakten Klasse eine Hilfe wäre.

m0rius

hallo,

ich würde mir auch Unterstützung für AOP wünschen. 😉
Verwende es derzeit noch nicht, überlege aber, dafür PostSharp zu verwenden - beruflich.

fg
hannes

ich würde mir auch Unterstützung für AOP wünschen. 😉

Da muss ich meinem Kollegen (und den anderen Vor-Postern) definitiv auch zustimmen.
WCF kann (zumindest auf der Server-Seite) schon eine Art AOP, und viel anders machens PostSharp und Konsorten ja auch nicht (ok, manche per IL weaving, andere per Proxy).

ich hätte gerne Standardparameter: int Test(int zahl1, int zahl2 = 5, int zahl3 = 8) { ... }