Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
The Future of C# (C# 4.0)
Gelöschter Benutzer

beantworten | zitieren | melden

das ist allerdings eine gute frage. evtl könnte das mal jemand teste, der schon die neue version hat? khalid :-) ?
kleines_eichhoernchen
myCSharp.de - Member

Avatar #avatar-2079.jpg


Dabei seit:
Beiträge: 3.971
Herkunft: Ursprünglich Vogtland, jetzt Much

beantworten | zitieren | melden

Zitat
IEnumerable<string> war bislang kein IEnumerable<object> ... jetzt schon.
Wird bereits ab v2.0 manuell vom Compiler in Arrays zelebriert. Der Compiler geht Rekursion den Vererbungsbaum durch und implementiert zusätzlich für jede Basis-Klasse die entsprechende Interfaces.

Persönlich kann ich mich mit "Co- und Contravarianz" von C# aber garnicht anfreunden. Wenn man eine Abwärtskombatibilität zu bestimmten Datentypen erreichen möchte, ist es für mich sinniger das manuell bei Bedarf zu implementieren. Eine Aufwärtskombatibilität find ich unsinnig.
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
private Nachricht | Beiträge des Benutzers
Khalid
myCSharp.de - Experte

Avatar #avatar-2534.gif


Dabei seit:
Beiträge: 3.511
Herkunft: Hannover

beantworten | zitieren | melden

Boah ist das noch verbuggt das ganze

Also, ich weis nicht, ob ich das jetzt richtig gemacht habe, aber ich musste den Aufrufer nochmals kompilieren, damit die Defaultwerte übernommen werden.

Vielleicht habe ich es auch falsch verstanden. Habe mal eben diese Schritte durchgemacht.
1)
Neue Klassenbibliothek mit einer Klasse


public class ParameterSample
{
  public void Bla(int i = 100, string s = "Hallo")
  {
    Console.WriteLine(String.Format("i = {0}, s = {1}", i, s));
  }
}
2)
Neue Konsolenanwendung. Referenz auf Klassenbibliothek.


static void Main(string[] args)
{
  ParameterSample sample = new ParameterSample();
  sample.Bla();
  sample.Bla(0);
  sample.Bla(0, "Leer");
}
Ausgabe

i = 100, s = Hallo
i = 0, s = Hallo
i = 0, s = Leer
3)
Jetzt habe ich in der Klassenbibliothek den Default von 100 auf 999 geändert, nur diese kompiliert und in das Anwendungsverzeichnis der Konsolenanwendung gelegt. Ohne die Konsolenanwendung neu zu kompilieren.
Ausgabe ist auch wieder

i = 100, s = Hallo
Erst als ich einmal die Konsolenanwendung neu kompiliert hatte, kam auch

i = 999, s = Hallo
bei raus.

War das so gemeint?

Achja, das folgende ist der Quellcode, den der Reflector für die Methode Bla ausspuckt.


public void Bla([Optional, DefaultParameterValue(0x3e7)] int i, [Optional, DefaultParameterValue("Hallo")] string s)
{
    Console.WriteLine(string.Format("i = {0}, s = {1}", i, s));
}
Es werden also keine Überladungen erzeugt, sondern per Attribute wird das ganze gesteuert.
"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)
private Nachricht | Beiträge des Benutzers
winSharp93
myCSharp.de - Experte

Avatar #avatar-2918.png


Dabei seit:
Beiträge: 5.742
Herkunft: Stuttgart

beantworten | zitieren | melden

Zitat von JAck30lena
das ist allerdings eine gute frage. evtl könnte das mal jemand teste, der schon die neue version hat?
Ok - ein kleiner Test:


class Program
{
    static void Main(string[] args)
    {
        Foo f = new Foo();
        f.Bar("Argument 1");
        f.Bar("Argument 1", s3: "Argument 3");
    }
}

public class Foo 
{ 
    public void Bar(string s1, string s2 = "Hallo", string s3 = "Test") 
    { 
        Console.WriteLine(); 
        Console.WriteLine(); 
    } 
}

Produziert laut Reflektor:


public class Foo
{
    public void Bar(string s1, [Optional, DefaultParameterValue("Hallo")] string s2, [Optional, DefaultParameterValue("Test")] string s3)
    {
        Console.WriteLine();
        Console.WriteLine();
    }
}

internal class Program
{
    private static void Main(string[] args)
    {
        Foo foo = new Foo();
        foo.Bar("Argument 1", "Hallo", "Test");
        string str = "Argument 3";
        foo.Bar("Argument 1", "Hallo", str);
    }
}

Und das muss ich jetzt einfach posten - so viel CPU-Last / RAM-Verbrauch und Ärger über die Performance der VM da drin steckt.
Auch wenn Khalid deutlich früher als ich dran war :evil:
Zitat von Khalid
Boah ist das noch verbuggt das ganze
Oh ja - bei mir ist VS 2x abgestürzt.
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

@Khalid

ja exakt so war das gemeint. und svenson hat recht, man muss neu kompalieren, was wiederrum schlecht ist.

das mit dem attributgesteuertem ist auch recht interessant aber der compiler schein momentan zumindest zur compilezeit den aufruf mit den parametern zu fixieren. evtl passiert da aber ncih etwas (hoffentlich)
winSharp93
myCSharp.de - Experte

Avatar #avatar-2918.png


Dabei seit:
Beiträge: 5.742
Herkunft: Stuttgart

beantworten | zitieren | melden

Zitat von JAck30lena
was wiederrum schlecht ist.
Andererseits kann man so sicher sein, dass stehst der Wert verwendet wird, von dem man bei der Entwicklung des Aufrufers glaubte, das er verwendet wird.
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

Zitat von Khalid
Also, ich weis nicht, ob ich das jetzt richtig gemacht habe, aber ich musste den Aufrufer nochmals kompilieren, damit die Defaultwerte übernommen werden.

Ich habs befürchtet... hab auch nochmal den Artikel über VB.NET gelesen. Unachtsam gelesen: Auch VB.NET macht den gleichen Müll wie C++ und jetzt auch C#.

Also: Finger weg von optionalen Parametern bei öffentlichen Methoden. Und wer es trotzdem benutzt, sollte sich klar sein, welche bösen Risiken er damit eingeht.

Ich bin wirklich ein wenig enttäuscht, dass sie so eine wackliges Sprachkonstrukt aufgenommen haben. Die Faulheit hat hier leider einen Sieg gegen Qualität davongetragen.

Kommt gleich auf die "Schwarze Liste" in den Coding-Richtlinien bei uns...
private Nachricht | Beiträge des Benutzers
Khalid
myCSharp.de - Experte

Avatar #avatar-2534.gif


Dabei seit:
Beiträge: 3.511
Herkunft: Hannover

beantworten | zitieren | melden

Zitat
Andererseits kann man so sicher sein, dass stehst der Wert verwendet wird, von dem man bei der Entwicklung des Aufrufers glaubte, das er verwendet wird.
Was eigentlich gar nicht so schlecht ist. Wäre IMHO ziemlich fatal, wenn aufeinmal die ganze Anwendung zickt, nur weil sich irgendwo in irgendeiner anderen Assembly ein Defaultwert sich ändert. Ist vielleicht jetzt etwas übertrieben, aber so erspart man sich möglichweise stundenlange Debugorgien.

Aber sonst stimme ich svenson zu. Dann bleibe ich lieber bei Methodenüberladungen. Da weis ich was passiert...
"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

man bräuchte sowas wie [Optional, Domianting] für defaultwerte, die sich bis zu den referenzierten assemblies durschlagen (also damit sie nicht compalieren müssen) und dann das gegenstück [Optional, Repressive].
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

Sofern du einen Wert angibst dominiert der. Wofür dann ein Sprachkonstrukt?
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

Zitat von Khalid
Was eigentlich gar nicht so schlecht ist. Wäre IMHO ziemlich fatal, wenn aufeinmal die ganze Anwendung zickt, nur weil sich irgendwo in irgendeiner anderen Assembly ein Defaultwert sich ändert.

Genau DAS produziert gerade die Lösung von VB.NET und C# 4.0.

Beispiel:

Du hast irgendwo eine Blockgröße von 32 KB als optionalen Wert. Der Aufrufer verzichtet bisher einen Wert zu setzen (im Code). Der Compiler setzt aber nun einen Aufruf mit 32 KB ein.

Jetzt ändert sich das Modul, welches die Funktion implementiert. Die maximal erlaubte Blöckgröße reduziert sich aber auch 16 KB, ebenso der Default-Wert des optionalen Parameters.

Modul compiliert (Aufrufer nicht), Anwendung gestartet und BOOOOOOM!

Würden Default-Werte auschließlich im Aufgerufenen implementiert, passiert das nicht.

Optionaler Parameter sollte heissen: "Da kümmer ich mich nicht drum, mir egal". Genau DAS ist nun nicht der Fall.

Man sollte also die Verwendung von optionalen Parametern auf Assembly-interne Methoden beschränken oder auf Felder, die garantiert unkritisch bei der Veränderung des Default-Wertes sind.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von svenson am .
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

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.....
Briefkasten
myCSharp.de - Member

Avatar #avatar-1523.gif


Dabei seit:
Beiträge: 446

Entwicklung von C# - Positiv / Negativ

beantworten | zitieren | melden

[EDIT=herbivore]Threads zusammengefügt[/EDIT]

Hallo,

und schon wieder kommt eine neue .NET C# Version (4) auf uns zu.

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

Seht ihr es positiv, dass es zu jeder Version Syntaktische Änderungen gibt?

Quelle: heise.de
Zitat
Eine mit dem Schlüsselwort "dynamic" deklarierte Variable löst nicht mehr der Compiler, sondern die CLR zur Laufzeit auf. In Visual Basic gab es dieses späte Binden schon zu Zeiten des klassischen Visual Basic durch den Typ "Object"; in C# ging das bisher nur umständlich über die Reflection-Bibliothek. Die dynamische Programmierung bietet Vorteile beim Umgang mit COM-Objekten und im Zusammenspiel mit dynamischen Programmiersprachen wie Python und Ruby. Auch mit optionalen und benannten Parametern zieht C# endlich gleich mit Visual Basic. Neu sind hingegen Co- und Contravarianz für Typparameter, die Zuweisungen zwischen Objektmengen mit verwandten Typen ermöglicht.
Zitat
Die neuen Sprachfunktionen halten sich demnach in Grenzen (verglichen mit den großen Wellen, die es in .NET 2.0 und .NET 3.5 gab). Interessant ist die Aussage von Mads Torgersen, Produktmanager für C#, im Dokument "New features in C# 4.0", dass C# und Visual Basic in Zukunft hinsichtlich ihrer Funktionen noch mehr im Gleichschritt gehen sollen als bisher. "Die Sprachen sollen sich in Stil und Gefühl unterscheiden, nicht in ihrem Funktionsumfang".

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.

Auch sind die Releases der .NET Versionen ziemlich knapp wie ich finde:

.NET 1.0 - 2002 - CLR 1.0
.NET 1.1 - 2003 - CLR 1.1
.NET 2.0 - 2005 - CLR 2.0
.NET 3.0 - 2006 - CLR 2.0
.NET 3.5 - 2008 - CLR 2.0
.NET 4.0 - 2009 - CLR ?

In dieser Tabelle sieht man auch sehr gut, dass sich seit dem .NET 2.0 Framework die CLR nicht mehr geändert hat. Ab dem dritten .NET Framework wurde es lediglich um Bibliotheken erweitert.

Findet ihr es gut, dass jedes 2te Jahr eine neue .NET Version released wir? Warum wir ein bestehendes .NET Framework nicht einfach um Bibliotheken erweitert ?
Was meint ihr?

Was meint ihr zur Thematik?
Schaut mal im IRC vorbei:
Server: https://libera.chat/ ##chsarp
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 49.486
Herkunft: Berlin

beantworten | zitieren | melden

Hallo Briefkasten,

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

herbivore
private Nachricht | Beiträge des Benutzers
winSharp93
myCSharp.de - Experte

Avatar #avatar-2918.png


Dabei seit:
Beiträge: 5.742
Herkunft: Stuttgart

beantworten | zitieren | melden

Hallo Briefkasten,

um nochmal meine Meinung zusammenzufassen:
Zitat von Briefkasten
Wie seht ihr den Entwicklungstrend von C#? Freut ihr euch auf die Erneuerungen oder seid ihr enttäuscht?
Ehrlich gesagt bin ich eher enttäuscht. So etwas wie non-nullable Typen aus Spec# hätten sie ruhig einbauen können.
Außerdem hätten sie ruhig Co- / Contravarianz beim Überschreiben vererbter bzw. implementieren von Membern erlauben können.
Zitat von Briefkasten
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.).

var sehe ich mehr als einen Workaround denn eine wirkliche Hilfe. Im Zusammenhang mit LINQ will man halt nicht immer zeilenfüllende Variablentypen schreiben...
Zitat von Briefkasten
In dieser Tabelle sieht man auch sehr gut, dass sich seit dem .NET 2.0 Framework die CLR nicht mehr geändert hat. Ab dem dritten .NET Framework wurde es lediglich um Bibliotheken erweitert.
Das 4er Framework kommt ja mit einer neuen CLR.
Mich persönlich störend die kurzen Releasezyklen nicht - im Gegenteil: Das zeugt IMHO von Innovation.
Zitat von Briefkasten
Warum wir ein bestehendes .NET Framework nicht einfach um Bibliotheken erweitert ?
Verstehe ich auch nicht so ganz - vermutlich Marketingzwecke...
"Für dieses Programm brauchen sie das .NET Framework in Version 2.0 mit der Windows Presentation Foundation mindestens in Version 3 und zusätzlich die WCF Runtime 1.5". (Versionen frei erfunden) Ist vielleicht doch besser so, wie es jetzt ist
private Nachricht | Beiträge des Benutzers
Golo Roden
myCSharp.de - Member

Avatar #avatar-2167.png


Dabei seit:
Beiträge: 4.207
Herkunft: Riegel am Kaiserstuhl

beantworten | zitieren | melden

Zum einen, vielleicht noch ganz lesenswert: http://www.des-eisbaeren-blog.de/post/2009/06/10/Fur-und-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.
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de
private Nachricht | Beiträge des Benutzers
kleines_eichhoernchen
myCSharp.de - Member

Avatar #avatar-2079.jpg


Dabei seit:
Beiträge: 3.971
Herkunft: Ursprünglich Vogtland, jetzt Much

beantworten | zitieren | melden

Zitat
Ich bin etwas enttäuscht, dass C# weg von den streng Typisierten Typen will. (var, dynamic)
Var ist streng typisiert. Der C#-Compiler nimmt den Typ der ersten Zuweisung. Eine spätere Zuweisung eines nicht implizit konvertierbaren Typs schlegt mit einer Compiler-Meldung fehl. bei Dynamic hast du ja schon selbst geschrieben, wozu dieses verwendet wird (für COM).
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
private Nachricht | Beiträge des Benutzers
Khalid
myCSharp.de - Experte

Avatar #avatar-2534.gif


Dabei seit:
Beiträge: 3.511
Herkunft: Hannover

beantworten | zitieren | melden

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 :)
"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)
private Nachricht | Beiträge des Benutzers
dN!3L
myCSharp.de - Experte

Avatar #avatar-2985.png


Dabei seit:
Beiträge: 2.891

beantworten | zitieren | melden

Hallo zusammen,
Zitat von Golo Roden
Zum einen, vielleicht noch ganz lesenswert: http://www.des-eisbaeren-blog.de/post/2009/06/10/Fur-und-wider-C-40.aspx
wie Golo auch, finde ich, dass "Ko- und Kontravarianz [...] mit Sicherheit nicht nur das am wenigsten beachtete, sondern auch am wenigsten verstandene Merkmal [sind] – zugleich jedoch auch das leistungsfähigste. Schließlich ermöglichen diese beiden Aspekte eine deutlich bessere Verwendung von Schnittstellen und implementierenden, aber spezialisierenden Klassen." Da habe ich mich schon mehr als oft drüber geärgert, dass das nicht ging.

Ebenso (wie schon mehrmals erwähnt) wären die optionalen Parameter ein schönes Feature gewesen - guckt man sich aber die Implementierung an, ist das aber eher fraglich. Sollte man sie wirklich einsetzten, muss man als Aufgerufener schon sehr sehr diszipliniert sein, damit das nicht irgendwann mal in die Hose geht.

Beste Grüße,
dN!3L

P.S.: Mit fehlt für ein "richtiges" neues C# noch der ??=-Operator
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 49.486
Herkunft: Berlin

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Golo Roden
myCSharp.de - Member

Avatar #avatar-2167.png


Dabei seit:
Beiträge: 4.207
Herkunft: Riegel am Kaiserstuhl

beantworten | zitieren | melden

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.
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von svenson am .
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 49.486
Herkunft: Berlin

beantworten | zitieren | melden

Hallo Golo Roden,
Zitat
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,
Zitat
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.
Zitat
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
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von svenson am .
private Nachricht | Beiträge des Benutzers
jaensen
myCSharp.de - Experte

Avatar #avatar-2657.png


Dabei seit:
Beiträge: 2.760
Herkunft: München

beantworten | zitieren | melden

Zitat von Briefkasten
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.
Zitat von winSharp93
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.
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 49.486
Herkunft: Berlin

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers