K
Optimizer schrieb:
So weit ich weiß, ist da noch nichts entschieden. Es gibt einige Anregungen (siehe Microsoft Connect)
Jaja, das Feedbackprogramm. Hat mich in der Vergangenheit enttäuscht. Vorschläge fließen so gut wie gar nicht ein. Aber gut, das ist MS' Bier. Was mich ärgert, sind die "won't fix"-Anworten auf knallharte Bug-Rückmeldungen. Das ist ärgerlich.
- special types wie delegate, enum constrainen zu können
Kenne ich kein Anwendungsbeispiel für. Selbst 'class' und 'struct' sind eigentlich nur bedingt brauchbar. Wie dem auch sei, ich konzentriere mich bei Connect eigentlich auf Bugs und nicht einmal die findet Microsoft beachtenswert (stimmt nicht ganz, sie reagieren drauf, aber nur, um "nein" zu sagen). Das Einbringen von Vorschlägen habe ich schon lange aufgegeben. Und Constraints finde ich da echt nebensächlich, erstmal muss Microsoft das Typensystem neu aufziehen. Das ist zum Henker, wenn man sich Delegates und Type inference anschaut. Aber hier schweifen wir wirklich ab.
Ich finde es nicht schlecht, explizit angeben zu müssen, welche Verträge mein Typ erfüllen will.
Wie gesagt, beide Vorgehen haben Vor- und Nachteile. Am .NET-Framework sieht man nunmal die Nachteile recht schön. An Haskell sieht man die Vorteile. Dort ist ja nun wirklich jede öffentliche Schnittstelle über einen Vertrag geregelt. Das macht das ganze sehr erweiterbar.
Aber auch das Konzept von C++ finde ich eben gut. Mit C++0x wird es noch besser, wenn C++ Typenkonzepte kennt, die Kontrakte abbilden. Dann entfällt nämlich der von Dir genannte Kritikpunkt mit den kryptischen Fehlermeldungen (obwohl man sagen muss, dass moderne Headerdateien das eh schon umsetzen. In VC++ 8 bekomme ich saubere, 1-Zeilen-lange Fehlermeldungen, wenn ein generischer Typ eine Schnittstelle nicht erfüllt. Das klappt super).
