The Future of C# (C# 4.0)

Das Problem ist letztlich doch, dass optionale Parameter und Überladung von Methoden für den Verwender die exakt gleiche Syntax haben, aber eine unterschiedliche Semantik.

Und das ist IMMER eine ganz schlechte Idee.

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":

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.

Hallo Golo Roden,

Das Problem ist letztlich doch, dass optionale Parameter und Überladung von Methoden für den Verwender die exakt gleiche Syntax haben, aber eine unterschiedliche Semantik.

nur die Aufrufsyntax ist (aus verständlichen Gründen) gleich. Aber die Definition ist auch für den Aufrufer (da sie Teil der Schnittstelle ist) erkennbar unterschiedlich, was bis in die Dokumentation durchschlägt. Es ist auch dort erkennbar (oder sollte es zumindest sein), ob es sich mehrere um Überladungen handelt oder um eine Methode mit optionalen Parametern.

Hallo svenson,

Sicher, aber wie bereits gesagt wurde: Optionale Parameter implizieren die Bedeutung: "Da muss ich mich nicht drum kümmern, wird schon".

nur weil es schon gesagt wurde, muss es nicht richtig sein. 😃 Ich sehe das nicht so. Was der Aufrufer intendiert, kann man nicht wissen. Ich habe ja, zwei Möglichkeiten genannt: Ist mir egal vs. nur Tipparbeit sparen (eine dritte wäre, dass es einfach übersichtlicher ist, wenn man den Default-Fall wegen seiner kurzen Parameterliste schneller erkennen kann). Wenn ich z.B. eine Datei öffne (File.Open), kann ich auch bestimmte Parameter weglassen, aber dann weiß ich trotzdem, was der Default ist und will das auch so. Es ist mir da keineswegs egal, was die Defaultwerte sind.

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.

Den Fall hatte ich ja selbst angesprochen. Wichtig ist aber, dass er sich eben nicht auf Default-Werte übertragen lässt.

herbivore

Ich sehe das nicht so.

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

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.

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.

Man darf die Dynamik in C# keineswegs als "neuen Weg" sehen. Viel mehr ist es so, dass ein Großteil der Neuerungen der Interoptibiltät dienen (Office, F# (DLR allgemein), etc.).

@winSharp93: Da habe ich aber die Befürchtung das es gerade Umsteiger von PHP etc. sehr gerne aufnehmen das so eine Gaudi in C# jetzt auch geht und wenn es nur mal kurz und der vollständigkeit halber in einem Lehrbuch auftauchte. Birgt halt wieder die Gefahr falsch gelerntes zu verinnerlichen, zu verwenden und dann letztendlich wieder falsch zu lehren.

Hallo svenson,

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