Laden...

The Future of C# (C# 4.0)

Erstellt von kyoko12 vor 15 Jahren Letzter Beitrag vor 14 Jahren 8.343 Views
K
kyoko12 Themenstarter:in
36 Beiträge seit 2008
vor 15 Jahren
The Future of C# (C# 4.0)

Hallo! Gestern war ja auf der PDC die Session "The Future of C#", in der Anders Heijlsberg die neuen Features von C# 4 vorgestellt hat.

Diese wären:

-Ein neuen, "dynamisch-statischer" Datentyp, der mit dem Schlüsselwort dynamic verwendet wird
-Optionale und benannte Parameter
-Verbesserte COM-Interop
-Verbesserte Co- und Contravariance, besonders bei Generics

Was haltet ihr von diesen Features? Ich finde, sie sind etwas schwach ausgefallen. Ich hätte mir die Design-by-Contract-Featrues von Spec# gewünscht.

Gelöschter Account
vor 15 Jahren

gibt es mehr informationen irgendwo im web?

5.742 Beiträge seit 2007
vor 15 Jahren

gibt es mehr informationen irgendwo im web?

Oder irgendwelchen Beispielcode, der die Features veranschaulicht?

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo kyoko12,

durch die Weiterentwicklung von C# wurden bisher einige wirklich brauchbare Features in C# hinzugefügt (ich sage nur Generics). Aber man muss auch aufpassen, dass man die Sprache nicht überfrachtet.

herbivore

5.742 Beiträge seit 2007
vor 15 Jahren

Inzwischen habe ich etwas Beispielcode gefunden.

Einige Passagen verwirren mich zwar noch mehr (die zur Co- und Contravarianz), aber trotzdem:
http://weblogs.asp.net/jguadagno/archive/2008/10/27/pdc-2008-experience-day-1-session-quot-the-future-of-c-quot.aspx

Gelöschter Account
vor 15 Jahren

**Dynamically Typed Objects:**also ich halte nicht viel von den dynamischen objekten. so wie ich das verstehe, kann man ohne explizite klassendefinition einfach dynamisch felder zum objekt hinzufügen. damit kann man viel schabanak treiben und das macht meiner meinung nach den code unübersichtlich, da man eigendlich nie sicher sagen kann, wie das objekt gerade aufgebaut ist.

Optional and Named Parameters
optionalae parameter hingegen finde ich sinnvoll. so spart man sich viele teils simple überladungen.

für den rest findet man nur unzureichend informationen....
nichtmal auf der ms-hp findet man detailierte informationen...

3.511 Beiträge seit 2005
vor 15 Jahren

Ich denke mal man muss mal schauen, welcher Sinn eigentlich hinter den dynamischen Objekten liegt. Da es noch keinerlei wirklich Infos gibt, würde ich sagen: "Abwarten".

Die optionalen Parameter finde ich ebenfalls extrem hilfreich. Endlich keine unnützen Überladungen mehr. Das macht den Code ein wenig "sauberer".

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

3.511 Beiträge seit 2005
vor 15 Jahren

Nachtrag zu dynamischen Objekten: Habe gerade noch gelesen, das man damit wirklich zur Laufezit dynamische Objekte hat.

Z.B.:


public class MyBag : DynamicObject  
{   
  // überschreibt Getter / Setter  
}  

dynamic b = new MyBag();
b.Id = 124;
b.Name = "Windows 7";
b.Price = 499.99m;  
b.IsAvailable = false;

Funktionsweise ist diese: Alle Properties werden in einen Dictonary<> gehalten. Man braucht also nicht mehr


b.Add("Id", 124);

schreiben. Sondern kann sofort eine Zuweisung schreiben. Ehrlich gesagt, finde ich das totale ka%!#. Aber naja, erstmal abwarten 🙂

BTW: Ist euch das 499.99m aufgefallen? Gibt es endlich einen Money Datentyp?

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

Gelöschter Account
vor 15 Jahren

m steht für decimal.

3.511 Beiträge seit 2005
vor 15 Jahren

OK, das ist oberpeinlich 😁

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

4.207 Beiträge seit 2003
vor 15 Jahren

Das mit Co- und Contravarianz finde ich nett, aber das mit dynamic ist eine Katastrophe ... so was ist nett, hat aber absolut NICHTS in C# verloren (meiner Meinung nach).

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

4.207 Beiträge seit 2003
vor 15 Jahren

**Dynamically Typed Objects:**also ich halte nicht viel von den dynamischen objekten. so wie ich das verstehe, kann man ohne explizite klassendefinition einfach dynamisch felder zum objekt hinzufügen. damit kann man viel schabanak treiben und das macht meiner meinung nach den code unübersichtlich, da man eigendlich nie sicher sagen kann, wie das objekt gerade aufgebaut ist.

Vor allem, da C# case-sensitiv ist, wird das besonders lustig ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

5.742 Beiträge seit 2007
vor 15 Jahren

Die dynamischen Datentypen wurde, so wie ich das verstanden habe, auch primär eingeführt, um Kompatibilität mit der DLR zu erreichen.
Ansonsten könnte man IMHO in C# keine F# Klassen verwenden.

Noch ein Zitat hierzu (aus einem Blog)

In C# 4.0 we simply declare a variable whose static type is dynamic.

Eine gewisse Typsicherheit ist also dennoch gegeben - man weiß von vornehinein, dass man es mit einem dynamischen Typ zu tun hat.

Gelöschter Account
vor 15 Jahren

Hallo Golo,

kannst du erklären, wozu "Co- und Contravarianz" gut ist und was man damit machen kann? ich habe dieses feature noch nicht richtig verstanden.

Eine gewisse Typsicherheit ist also dennoch gegeben - man weiß von vornehinein, dass man es mit einem dynamischen Typ zu tun hat.

das problem ist, das viele leute dann dazu neigen dies allgemein einzusetzen, da sie denken das dynamisch immer cool ist und das kann schnell ausarten. wenn man das gebraucht hat um DLR zu ermöglichen kann ich es gut verstehen nur ist das misbrauchspotenzial enorm. schön wäre z.b.. wenn man explizit angeben müsste, wo solche objekte gültig sind, damit man den restlichen code davon sauber halten kann oder damit man weiß, das man an entsprechenden stellen auf dynamische objekte stoßen kann.

J
130 Beiträge seit 2008
vor 15 Jahren

OK, das ist oberpeinlich 😄

lol !

**“DOH !” -Homer Simpson**
4.207 Beiträge seit 2003
vor 15 Jahren

Hallo Golo,

kannst du erklären, wozu "Co- und Contravarianz" gut ist und was man damit machen kann? ich habe dieses feature noch nicht richtig verstanden.

IEnumerable<string> war bislang kein IEnumerable<object> ... jetzt schon.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

5.742 Beiträge seit 2007
vor 15 Jahren

jetzt schon.

Aber was hat es in diesem Zusammenhang mit den "in" und "out" Schlüsselwörtern auf sich?
Oder sind die nochmal für etwas anderes da?

U
1.688 Beiträge seit 2007
vor 15 Jahren

Richtige optionale Parameter, also nicht der Params[] Workaround, fehlten wirklich noch. Hätte man das nicht gleich von C++ mitnehmen können?

5.742 Beiträge seit 2007
vor 15 Jahren

Richtige optionale Parameter,

Soll es anscheinend geben:

Optional Parameters

  
public StreamReader OpenTextFile(string path; Encoding = null; bool detectEncoding = true; int bufferSize = 1024)  
  

Named Arguments

  
OpenTextFile("foo.txt", Encoding.UTF8, buffersize: 4096);  
  

Oder meinst du etwas Anderes?

U
1.688 Beiträge seit 2007
vor 15 Jahren

Oder meinst du etwas Anderes?

Nein, genau das. Sie fehlten (bzw. fehlen 😉) vor der Einführung von C# 4.
Nur in C++ gibt's sie ja schon lange oder gar schon immer.

4.207 Beiträge seit 2003
vor 15 Jahren

jetzt schon.
Aber was hat es in diesem Zusammenhang mit den "in" und "out" Schlüsselwörtern auf sich?
Oder sind die nochmal für etwas anderes da?

Du musst IEnumerable<out string> schreiben, wenn Du es auch als IEnumerable<object> ansprechen können willst.

Mit IEnumerable<in object> kannst Du das Gegenteil erreichen, dass Du das Ding auch als IEnumerable<string> ansprechen kannst.

Das ganze funktioniert, so lange es nur um Referenzkonvertierung geht, Boxing und Unboxing wird nicht unterstützt. object und string funktioniert also, object und int aber nicht.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

Gelöschter Account
vor 15 Jahren

Du musst IEnumerable<out string> schreiben, wenn Du es auch als IEnumerable<object> ansprechen können willst.

Mit IEnumerable<in object> kannst Du das Gegenteil erreichen, dass Du das Ding auch als IEnumerable<string> ansprechen kannst.

wozu soll das gut sein?

4.207 Beiträge seit 2003
vor 15 Jahren

Um zB ein IEnumerable von Businessobjekten machen zu können, dann aber spezialisiert auf eine Subklasse von BusinessObject zugreifen zu können.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

Gelöschter Account
vor 15 Jahren

du meinst damit man sowas schreiben kann?


foreach(subklasse s in businessobject){....}
S
8.746 Beiträge seit 2005
vor 15 Jahren

Falls die optionalen Parameter implementiert sind wie in C++, wäre es eine deutliche Verschlimmbesserung der Sprache. Ich vermute aber, es handelt sich um Compiler-Magic. Vermutlich werden die Default-Werte deskriptiv als Attribute abgelegt und durch den Callee implementiert. Das bedeutet aber: Letztlich geht doch wieder alles über Params. Das hätte zur Folge, dass Funktionen mit optionalen Parameter eine Laufzeiteinbuße hinnehmen müssen.

1.378 Beiträge seit 2006
vor 15 Jahren

Ich könnte mir eher vorstellen, dass diese Default-Werte in verschieden überladene Methoden aufgelöst wird.

Lg XXX

K
kyoko12 Themenstarter:in
36 Beiträge seit 2008
vor 15 Jahren

Hab noch mal ein bisschen im Web geschaut und folgendes Dokument von Microsoft gefunden: New features in CSharp 4.0.docx

Ist in etwa das gleiche, wie es das damals für C# 3.0 gab, eine kurze Zusammenfassung zu den neuen Features.

Zu den dynamischen Features möchte ich sagen: Es ist ja nicht so, dass C# selbst dynamisch wird, man kann nur auf dynamische Objekte zugreifen. Das halte ich schon für sinnvoll, wenn man beachtet, welchen Zuspruch Sprachen wie IronPython in letzter Zeit bekommen.

EDIT:

Was mir übrigens aufgefallen ist: Wieso zur Hölle wird für die Zuweisung von benannten Parametern der : verwendet, wenn etwas Ähnliches für Attribut-Konstruktoren bereits mit = gelöst ist?

Gelöschter Account
vor 15 Jahren

also das mit den optionalen parametern ist compilersache. siehe:

public void M(int x, int y = 5, int z = 7);
Here y and z are optional parameters and can be omitted in calls:
M(1, 2, 3); // ordinary call of M
M(1, 2); // omitting z – equivalent to M(1, 2, 7)
M(1); // omitting both y and z – equivalent to M(1, 5, 7)

Gelöschter Account
vor 15 Jahren

Was mir übrigens aufgefallen ist: Wieso zur Hölle wird für die Zuweisung von benannten Parametern der : verwendet, wenn etwas Ähnliches für Attribut-Konstruktoren bereits mit = gelöst ist?

weil im methodenaufruf ein "=" eine zuweisung ist. in der signatur ist er der defaultwert.

S
8.746 Beiträge seit 2005
vor 15 Jahren

also das mit den optionalen parametern ist compilersache

Die Frage ist nur: Wie implementiert. Die C++-Variante produziert potentielle Versionierungsprobleme in dynamisch gebundenen Anwendungen. Anders formuliert: Wird der Default-Wert geändert, muss der Aufrufer neu compiliert werden.

*EDIT*

Angeblich soll es genauso funzen wie in VB.NET. Hier wird intern mit params gearbeitet. Also kein Versionsierungsproblem.

Gelöschter Account
vor 15 Jahren

das ist allerdings eine gute frage. evtl könnte das mal jemand teste, der schon die neue version hat? khalid 🙂 ?

3.971 Beiträge seit 2006
vor 15 Jahren

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...

3.511 Beiträge seit 2005
vor 15 Jahren

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));
  }
}

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

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)

5.742 Beiträge seit 2007
vor 15 Jahren

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:

Boah ist das noch verbuggt das ganze

Oh ja - bei mir ist VS 2x abgestürzt.

Gelöschter Account
vor 15 Jahren

@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)

5.742 Beiträge seit 2007
vor 15 Jahren

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.

S
8.746 Beiträge seit 2005
vor 15 Jahren

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...

3.511 Beiträge seit 2005
vor 15 Jahren

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)

Gelöschter Account
vor 15 Jahren

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].

S
8.746 Beiträge seit 2005
vor 15 Jahren

Sofern du einen Wert angibst dominiert der. Wofür dann ein Sprachkonstrukt?

S
8.746 Beiträge seit 2005
vor 15 Jahren

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.

Gelöschter Account
vor 15 Jahren

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.....

446 Beiträge seit 2004
vor 14 Jahren
Entwicklung von C# - Positiv / Negativ

[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

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.

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

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo Briefkasten,

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

herbivore

5.742 Beiträge seit 2007
vor 14 Jahren

Hallo Briefkasten,

um nochmal meine Meinung zusammenzufassen:

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.

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...

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.

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 😉

4.207 Beiträge seit 2003
vor 14 Jahren

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

3.971 Beiträge seit 2006
vor 14 Jahren

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...

3.511 Beiträge seit 2005
vor 14 Jahren

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

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)

2.891 Beiträge seit 2004
vor 14 Jahren

Hallo zusammen,

Zum einen, vielleicht noch ganz lesenswert:
>

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 😉

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo 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.

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:

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