Erste Details zu C# 3.0 von Anders Hejlsberg
Einige Sachen werden wohl aus Comega übernommen. In den Quellen spricht er ja hauptsächlich von XML aber ich wünsch mir so die Streams aus Comega - des programmiert sich echt gut.
Baka wa shinanakya naoranai.
Mein XING Profil.
Original von talla
Einige Sachen werden wohl aus Comega übernommen.
Denke ich auch.
Er spricht aber auch von den Unterschieden der OO- und der relationalen Welt ( SQL ), dass lässt hoffen.
Naja, ich persönlich sehe die Ankündigung, in C# Konstrukte zur Datenabfrage zu integrieren, eher kritisch. Aus C# jetzt eine Art objektrelationale Programmiersprache zu machen, lässt bei mir gemischte Gefühle aufkommen.
Heijlsberg sollte sich genau überlegen, was er wirklich in die Sprache einbauen will, sonst haben wir am Ende ein ähnlich unübersichlichen und kaum noch zu implementierenden Standard wie das C++-Komitee.
Glücklicherweise bin ich nicht allein mit dieser Meinung, denn im Channel 9 Forum gibt es auch Leute, die das ähnlich sehen wie ich ...
I am Jack's smirking revenge.
I am Jack's raging bile duct.
I am Jack's cold sweat.
I am Jack's complete lack of surprise.
I am Jack's broken heart.
I am Jack's wasted life.
Klar darf man nicht einfach alles blind implementieren was gerade so "in" ist an Techniken, weil dann wäre Comega schon Version 3 von C#, ist es aber nicht. So wie dort aber XML z.B. integriert ist, find ich schon Klasse. Und denke mal die werden mit Comega als Experimentalsprache viel Erfahrungen sammeln wie sehr sich einige Konzepte für C# eignen.
Baka wa shinanakya naoranai.
Mein XING Profil.
Die "SQL-Integration" entpuppt sich beim zweiten Hinsehen ja als IEnumerable-Abfragesprache. Bleibt natürlich die Frage, wo außer bei SQL das mit Gewinn eingesetzt werden kann. Generell folgt das natürlich dem aktuellen Trend mehr und mehr deklarativ zu arbeiten.
Ich sehe zumindest den Gewinn, auch hier Typisierung zu bekommen und somit etliche Fehler zu vermeiden.
Original von svenson
Ich sehe zumindest den Gewinn, auch hier Typisierung zu bekommen und somit etliche Fehler zu vermeiden.
Sehe ich auch so. Das hat A.H. ja auch angesprochen.
Grundsätzlich finde ich auch Innvoation in dem Bereich begrüßenswert. Wenn man mal ehrlich ist, sind solche wirklich revolutionären Ansätze in letzter Zeit doch ziemlich selten zu finden. Ebenfalls diskutieren wird ja, bestimmte Merkmale funktionaler Programmiersprachen aufzunehmen. Dem wäre ich auch nicht abgeneigt.
Original von svenson
Grundsätzlich finde ich auch Innvoation in dem Bereich begrüßenswert. Wenn man mal ehrlich ist, sind solche wirklich revolutionären Ansätze in letzter Zeit doch ziemlich selten zu finden. Ebenfalls diskutieren wird ja, bestimmte Merkmale funktionaler Programmiersprachen aufzunehmen. Dem wäre ich auch nicht abgeneigt.
Welche Merkmale wären das?
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
Original von Quallo
Welche Merkmale wären das?
Schau dir mal bei MSDN Artikel zum Thema F# an. Genau wie COmega eine Experimentalsprache, diesmal aber eben funktional.
Hier kann man übrigens die Spezifikation runterladen:
Einige Dinge seh ich aber immernoch kritisch. Viele Syntaxerweiterungen sind oft nur Aliase für Methodenaufrufe in Collections. Man hätte die gleichen Effekte auch mit deutlich weniger Syntaxmodifikationen hinbekommen.
Ob ich nun schreibe:
from c in customers
where c.City == "London"
select c.Name
oder
customers.
Where(c => c.City == "London").
Select(c => c.Name)
ist eigentlich wurst, denn Oberes wird ja eh in die untere Schreibweise übersetzt. Außerdem integriert sich ja die letztere Version schon in die bestehende Sprachdefinition von C# (Bis auf die Lambda Ausdrücke, die schon cool sind). Ich seh die Aufnahme neuer Schlüsselwörter eher mit Skepsis. Lisp braucht z.B. überhaubt keine neuen Syntaxkonstrukte und ist trotztem beliebig erweiterbar.
Keep it small and simple.
I am Jack's smirking revenge.
I am Jack's raging bile duct.
I am Jack's cold sweat.
I am Jack's complete lack of surprise.
I am Jack's broken heart.
I am Jack's wasted life.
Ich hab mal in den Link von maxE reingeschaut.
Objekt- und Collection-Initializers sind eine gute Idee, finde ich. Man kann dann alle (?) Typen schon bei der Deklaration/Instanziierung vollständig initialisieren. So wie man es heute von Arrays her kennt.
List<string> stringList = new List<string> {"abc", "def", "ghi"};
Person p = new Person {Name="Gonzo", Age=28};
Der Sinn hinter impliziter Typisierung hat sich mir auf die Schnelle nicht erschlossen.
var i = 5; // int i
var s = "abc"; // string s
Was soll es bringen, den Typ nicht mit anzugeben, was wird dadurch vereinfacht? Ich seh's schon kommen, in C# 4.0 gibt es den Variant-Typ.
Zur ClientCallback Geschichte in ASP.NET, ist folgender Link interessant.
Atlas Project
Infer data type ... sprich das var-Schlüsselwort ... sollte laut Anders Heijlsberg nur dann eingesetzt werden, wenn es nicht ohne geht ...
Bei int und string ist es Quatsch, aber bei anonymen Datentypen geht es nicht anders. Und bei Abfragen mit Instanziierung ohne Konstruktor benötigt man das ...
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden