The Future of C# (C# 4.0)

ich schließe mich svenson an. optional heißt im moment nur "ich muss nciht tippen" und hat daher keinen nennenswerten mehrwert. mir würde es mehr gefallen, wenn sich die änderung an allen refernzierenden assemblies auswirkt. weil wenn ich definitiv einen wert benötige, dann setze ich diesen wert sowieso. auch wenn dieser der defaultwert ist. gefährlich ist es daher auch einfach nichts einzutippen, weil man denkt das der default sowieso der ist den man haben will.....

Hallo Briefkasten,

in dem Thread, an den ich deinen Beitrag angehängt habe, sind einige deiner Fragen schon beantwortet.

herbivore

Zum einen, vielleicht noch ganz lesenswert:  http://www.des-eisbaeren-blog.de/post/20...wider-C-40.aspx

Zum zweiten: Zu der Frage "Warum eine neue CLR?" - sie hätten die Erweiterungen für die Parallelprogrammierung in die 2.0 nicht wirklich gut integriert bekommen, ohne etwas verändern zu müssen. Daher die neue Version.

Sieht man auch sehr schön, wenn man die TPL mal als CTP für 2008 und die aus VS 2010 Beta 1 vergleicht - die von 2010 ist um Längen schneller.

Zitat:

Wie seht ihr den Entwicklungstrend von C#? Freut ihr euch auf die Erneuerungen oder seid ihr enttäuscht?

Freuen:
Ich finde dynamic sehr interessant. Im Bereich Office Interop wird dadurch vieles leichter und einfacher. Kein ewiges (ref missing, ref missing , ref missing, ... ;)) mehr. Das macht jetzt der Compiler für einen.

Enttäuscht und IMHO der wohl größte Fehler:
Optionale Parameter

Zitat:

Warum wir ein bestehendes .NET Framework nicht einfach um Bibliotheken erweitert ?

Naja, wird es ja an sich. Nur die CLR 4.0 musste sein, da einige Sprachfeatures einfach für die CLR 2.0 zu viel wären. Paralells wurde ja bereits genannt. Alle weiteren späteren Featuren werden danach wahrscheinlich wieder auf die CLR 4.0 aufbauen. Hoffe ich jedenfalls :)

Hallo Briefkasten,

Zitat:

Ich bin etwas enttäuscht, dass C# weg von den streng Typisierten Typen will. (var, dynamic). Das geht immer mehr in Richtung Visual Basic.NET.

wie schon gesagt ist var nur eine Schreiberleichterung, die aber sofort zur Compilezeit in einen konkreten Typ aufgelöst wird und dadurch streng typisiert ist. Und dynamic muss man ja nicht nutzen. Wenn man es nicht tut, ist auch weiterhin alles zur Compilezeit festgelegt und streng typisiert. dynamic ist also eine optionale Erweiterungen, die man benutzen kann, wenn man will, die aber nichts aufweicht, wenn man sie nicht benutzt. Und var weicht nicht mal etwas auf, wenn man es benutzt.


Hallo svenson, hallo zusammen,

um nochmal auf die Sache mit den optionalen Parametern/Default-Werten zurück zu kommen:

Zitat:

Du hast irgendwo eine Blockgröße von 32 KB als optionalen Wert. [...] Die maximal erlaubte Blöckgröße reduziert sich aber auch 16 KB.

Dein Beispiel knallt doch nicht wegen des eincompilierten Default-Werts, sondern weil sich der zulässige Wertebereich für den Parameter geändert hat. Es ist doch - auch ohne Default-Werte - der Normalfall, dass die konkreten Parameterwerte im Aufrufer stecken. Die 32 hätte ja nicht nur per Default-Wert in den Code des Aufrufers kommen können, sondern einfach durch die bewusste Entscheidung des Aufrufers, explizit 32 zu übergeben. Und dann würde es in deinem Beispiel genauso knallen. Sprich das Problem sind nicht die Default-Werte, sondern die Änderung der Schnittstelle. Daher finde ich dein Beispiel ungeeignet und sogar irreführend.

Deine Argumentation, dass es schlecht ist, wenn der Compiler Konstanten aus dem Code des Aufgerufenen in den Code des Aufrufers "injiziert", mag bei bei const vs. readonly stimmen, aber bei Default-Parametern nicht.

Es kommt nicht mal darauf an, was es für den Aufrufer bedeutet, wenn er einen Parameter beim Aufruf weglässt. Also ob er sich sagt "Da kümmer ich mich nicht drum, mir egal." oder "Ich will genau diesen Wert, aber kann mir das Tippen sparen." Fakt ist, dass eine Anwendung weiterhin funktionieren muss, wenn sich eine benutze DLL ändert, sonst ist es ein breaking change.

Wir reden hier also allenfalls über eine möglicherweise höhere oder niedrigere Flexibilität beim Ändern des aufgerufenen Codes. Aber da halte ich es gar nicht für ausgemacht, wann die Flexibilität höher ist. Es kommt vermutlich auf den Einzelfall an, ob die Flexibilität höher ist, wenn man Default-Werte per Überladungen (Default-Wert ist in den Aufgerufenen compiliert) oder per optionale Parameter (Default-Wert ist in den Aufrufer compiliert) realisiert. Aber alleine, dass man diese Wahlmöglichkeit jetzt hat, erhöht doch schon die Flexibilität. Die einzige Frage ist, ob diese Flexibilität von den Programmierern auch bewusst eingesetzt wird.

herbivore

Zitat von herbivore:

Die 32 hätte ja nicht nur per Default-Wert in den Code des Aufrufers kommen können, sondern einfach durch die bewusste Entscheidung des Aufrufers, explizit 32 zu übergeben. Und dann würde es in deinem Beispiel genauso knallen.

Sicher, aber wie bereits gesagt wurde: Optionale Parameter implizieren die Bedeutung: "Da muss ich mich nicht drum kümmern, wird schon". Also bewußt keine bewußte Entscheidung. Das gleiche Problem gilt übrigens auch für öffentliche Konstanten. Auch die werden beim Aufrufer fest eincompiliert. Daher in öffentlichen Schnittstellen besser readonly-Felder verwenden, sofern sich der Wert später mal ändern könnte.

Hier nochmal eingehender:

 http://dotnet.mvps.org/dotnet/articles/optional/

Bemerkenswert die "Kritik an der Kritik":

Zitat:

Die angeführten Gründe halten jedoch einer eingehenden Prüfung nicht stand. Der erste Kritikpunkt ist rein theoretischer Natur, da optionale Parameter mit Standardwerten in Szenarien nicht geeignet sind, in denen der Standardwert nicht unumstößlich feststeht.

Der Hinweis zur Verwendung ist richtig, aber hier ist der gute Mann doch wohl ein wenig optimistisch, was die Disziplin der Entwickler angeht. C# ist mal unter dem Banner "defensives Programmiermodell" angetreten, mit dem Ziel Qualität über Faulheit stellen. Optionale Parameter sind wohl ein deutliches Zeichen für die Abkehr von dieser Strategie und geben den Kritikern an C# wohl recht, die sagen, dass die Sprache mehr und mehr verwurschtelt wird.

Flexibilität kann ich in diesem Zusammenhang nicht erkennen, außer dass der Entwickler nun so flexibel ist, eine fehleranfällige und eine fehlerunanfällige Implementierung zu wählen.

Zitat von herbivore:

Ich sehe das nicht so.

Ich antworte darauf nochmal mit dem "Kritiker der Kritik":

Zitat:

Die angeführten Gründe halten jedoch einer eingehenden Prüfung nicht stand. Der erste Kritikpunkt ist rein theoretischer Natur, da optionale Parameter mit Standardwerten in Szenarien nicht geeignet sind, in denen der Standardwert nicht unumstößlich feststeht.

Aber erkläre mir doch nochmal inwiefern sich Konstanten im Versionierungsproblem von optionalen Parametern untscheiden. Hier ist für den Entwickler wegen des Wortes "const" vielleicht noch eher klar, worum es sich handeln sollte. Aber an der nächsten Ecke lauern auch hier schon wieder die "Performance-Optimierer" die mal gehört haben, dass const schneller ist als readonly. Von den C-Umsteigern, die const aus Gewohnheit verwenden, ganz zu schweigen...

Aber wir reden wohl aneinander vorbei: Es geht mir nicht um die korrekte und dann auch sichere Verwendung von const und optional, sondern um das Gefahrenpotential die sie für unerfahrene Entwickler bergen.

Hallo svenson,

Zitat:

Aber erkläre mir doch nochmal inwiefern sich Konstanten im Versionierungsproblem von optionalen Parametern untscheiden.

der Unterschied ist eben, dass man optionale Parameter immer auch explizit angeben kann, d.h. die 32 in deinem Beispiel steht nicht nur dann im ausführbaren Code des Aufrufers, wenn der Default-Wert verwendet wurde, sondern auch, wenn der Aufrufer die 32 explizit angegeben hat. Es ist im ausführbaren Code im Prinzip gar nicht mehr zu erkennen, warum da eine 32 steht, da wir über den Fall reden, in dem der Quellcode des Aufrufers nicht neu compiliert wird. Bei Änderungen der DLL muss diese also so oder so damit klar kommen, dass möglicherweise 32 übergeben wird. Die Default-Parameter ändern also nichts zum Negativen. Es ist sogar eigentlich ein Vorteil, wenn der Default-Wert im Aufrufer steckt. Denn mit diesem wurde er getestet und funktioniert. Wenn die Bibliothek also keine Breaking Changes enthält, wird er auch weiter damit funktionieren. Das wäre nicht unbedingt der Fall, wenn der Aufgerufene einen anderen Default-Wert erzwingen könnte, wie das beim Überladen der Fall ist.

Das ist schon etwas anders als bei const, wo bei Änderungen die Konstantenwerte im ausführbaren Code nicht mehr stimmen, wenn nicht alles compiliert wird. Das ist ein echter Nachteil.

Aber auch ich habe auch den Eindruck, dass wir aneinander vorbei reden. Vielleicht äußern sich ja die anderen, wie sie das ganze sehen, nachdem sie die Argumente für beide Seiten gehört haben.

herbivore