Laden...

Was wünscht ihr euch für C# 5?

Erstellt von pdelvo vor 14 Jahren Letzter Beitrag vor 13 Jahren 43.486 Views
F
10.010 Beiträge seit 2004
vor 13 Jahren

Naja, ich werde alt, da verwechsele ich schon mal den einen oder anderen.
Knuth==Tex, Tannenbaum == Minix.

K
593 Beiträge seit 2007
vor 13 Jahren

Hallo Community,

habe gerade angefangen mich ein wenig mit scala zu beschäftigen und fand da etwas an Syntax überaus angenehm..^^

Eine For-Schleife ganz einfach in :


for (i <- 0 to 2)

Ich finde das irgendwie ultra angenehm zu lesen, man muss auch nicht i explizit nen Typ geben er hat einfach durch die zuweisen einen Int. Sowas fände ich auch für C# gut was ja eine erweiterung von Lamdba wäre oder?

Naja sowas würde ich mir wünschen 😃

Viele Grüße,

Kaji

6.912 Beiträge seit 2009
vor 13 Jahren

Hallo,

ist fast wie in VB 😉

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

C
401 Beiträge seit 2007
vor 13 Jahren

Hi,

for in Scala ist keine Schleife, sondern eine Comprehension. Und einfach durch das Zuweisen ist auch nicht ganz richtig, der Compiler erkennt den Typen, Stichwort: Type inference.

Wo wir schon bei Scala sind.. ein wirklich cooles Feature wäre Pattern Matching im Scala-/Erlang-Style.

4.207 Beiträge seit 2003
vor 13 Jahren

Falls das das gleiche ist wie bei F#: FULLACK

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

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

C
401 Beiträge seit 2007
vor 13 Jahren

Falls das das gleiche ist wie bei F#: FULLACK

Hab mir gerade das Pattern Matching in F# angeschaut und muss sagen, dass das von Scala noch mächtiger ist. Vor allem dadurch, dass Scala eine objekt-funktionale Sprache ist. Beispiel für ein cooles Feature sind Extraktoren. So kann man quasi die Werte aus einem Objekt extrahieren, oder auch Werte vorgeben, bei denen es sich anders verhalten soll:



object Test {
  case class Person(val name: String, val age: Int)
  case class Square(val size: Int)

  def main(args: Array[String]) {
    val p = Person("Joe", 42)
    val s = Square(10)

    matchTest(p)
    matchTest(s)
    matchTest(Array(1,2,3))
  }

  def matchTest(a: Any) = a match {
    case Person("Joe", a) => println("Oh no, it's Joe.")
    case Person(n,a) => println(String.format("Person with name: \"%s\" and age: \"%s\".", n, a.toString))
    case Square(s) => println(String.format("Square with size: \"%s\".", s.toString))
    case _ => println("Unknown object.")
  }
}

führt zur Ausgabe:


Oh no, it's Joe.
Square with size: "10".
Unknown object.

Aber nicht nur das geht, man kann auch einfach auf Typen checken und hat dann gleich dann gleich eine Variable vom richtigen Typen zur Verfügung:


val p = Person("Joe", 42)

p match {
  case x: Person => println(x.name)
}

Und auch mit Regex kann man tolle Dinge tun. Aber das würde jetzt hier den Rahmen sprengen 😉

1.361 Beiträge seit 2007
vor 13 Jahren

Hab mir gerade das Pattern Matching in F# angeschaut und muss sagen [...]

Schau dir mal "Active Patterns" an. Damit kannste auch normale .NET-Strukturen in den Patterns analysieren. Genauso wie in dem Scala-Snippet von dir.

beste Grüße
zommi

C
401 Beiträge seit 2007
vor 13 Jahren

Schau dir mal "Active Patterns" an. Damit kannste auch normale .NET-Strukturen in den Patterns analysieren. Genauso wie in dem Scala-Snippet von dir.

Ah, okay... die wurden in dem ersten Beitrag den ich gelesen habe garnicht erwähnt 😉. Dann ist es wohl doch recht ähnlich.

6.912 Beiträge seit 2009
vor 13 Jahren

Hallo,

es gibt nun offizielle Meldungen was bei C# 5.0 dabei sein wird.
Siehe Asynchrony in C# 5

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

1.044 Beiträge seit 2008
vor 13 Jahren

Hallo zusammen,

kürzlich kam ich auf die Idee mit generischen Attributen. Es hört sich ein wenig übertrieben an, aber wenn man sich das durch den Kopf gehen lässt, wird einen einiges klarar und man versteht, dass es doch einen Nutzen gibt. Ich habe bei bei Microsoft die Anfrage gestellt - mal sehen, was die dazu sagen. Hier findet ihr weitere Informationen: Generic attributes.

Hier noch kurz das Beispiel, das ich dort auch gepostet habe:

For my own purposes, I need a generic attribute. For example, I have an attribute "ValidateWithCondition" where I can specify a condition for a validation rule. Furthermore, it should be possible to declare a LINQ expression. Here an example:

[ValidateWithCondiation<IMyValidationRuleInterface>( () => ... > ( ) ]

Another practice would be a generic condition or expression instead of writing the Type(Sytem.Type, i.e. typeof()).

I would like to know if there as been any other request concerning generic attributes. I wonder why this is not a built-in feature.

Was meint ihr dazu? Für mich wäre sowas wirklich toll, weil es immer einige Situationen gibt, wo genau so was richtig praktisch ist.

zero_x

2.891 Beiträge seit 2004
vor 13 Jahren

kürzlich kam ich auf die Idee mit generischen Attributen

Naja, es würde ja erstmal reichen, mehr Typen für Attributparameter zuzulassen. Sodass es nicht mehr zu Compilerfehler CS0182 (Ein Attributargument muss ein constant-, typeof- oder Arrayerstellungsausdruck eines Attributparametertyps sein.) kommt. Vgl. auch How to pass objects into an attribute constructor - Stack Overflow. AFAIK gibt es diese Beschränkung, damit die Attribute direkt in die Assemblymetadaten serialisiert werden können.

Aber ja, über die (momentane) Beschränkung habe ich mich auch schon öfters geärgert.

360 Beiträge seit 2005
vor 13 Jahren

Weil es trotzdem bedingt hier reingehört - auch wenn es nicht das ist war wir uns wünschen, sondern das was Microsoft ungeachtet dessen macht 😉

Microsoft hat auf der PDC bekanntgegeben wo der Hauptfokus der Weiterentwicklung von C# und VB liegen wird: heise.de: PDC: Asynchrone Zukunft bei C# 5.0 und Visual Basic 11.0

1.044 Beiträge seit 2008
vor 13 Jahren

Hallo zusammen,

ein weiteres Feature, was ich mir wünsche: Events in object and collection initializers.

In C# I very often use the object and collection initializers. If I have for example a class, I write following:

List<Person> people = new List<Person>  
{  
    new Person { Firstname="Daniel", Age=17 },  
    new Person { Firstname="Eric", Age=28 }  
}  
  

I also use a similar syntax on events. Here an example:

MyEvent += (s,e) =>  
{  
    // Operation.  
}  

As you can see these syntaxes are very similar. Unfortunally, it is not possible to mix these two syntaxes together. I think this would be a very great feature! Here an example which I could imagine:

List<Person> people = new List<Person>  
{  
    new Person  
    {  
        Firstname="Daniel",  
        Age=17,  
        OnAgeChanged += (s,e) =>  
        {  
            MessageBox.Show("Happy Birthday!");  
        }  
    },  
    new Person { /* ... */ }  
};  

Why does C# not support this feature?

zero_x

U
457 Beiträge seit 2006
vor 13 Jahren

Ich hatte mal eine äußerst dämliche Situation. Code sah ungefähr so aus nur mit einer for Schleife innen. Ich glaube bei Java geht sowas. In C# habe ich keine Lösung gefunden(ohne Flags benutzen zu müssen)


labelOfOuterLoop: while(true) 
{
   while(true) 
   {
       break labelOfOuterLoop;   
   }
}

6.912 Beiträge seit 2009
vor 13 Jahren

Hallo Second Sun,

das kommt ursprünglich von Fortran. In C# ist das die einzige Ausnahme wo Goto möglich ist -> das wurde im Forum aber bereits behandlet. Suche mal danach.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

6.862 Beiträge seit 2003
vor 13 Jahren

In C# ist das die einzige Ausnahme wo Goto möglich ist

Nicht ganz, in Switch Statements benötigt man auch unter Umständen Gotos, da C# kein implizites Fallthrough bei den Cases kennt, wenn sie Code enthalten.

Baka wa shinanakya naoranai.

Mein XING Profil.

X
1.177 Beiträge seit 2006
vor 13 Jahren

huhu,

explizite Compilerfehler ala
*Please use Generics like List<Type> instead of StringCollection, ArrayList.. *Please use using or Try-finally for Types implementing IDisposeable

nen Parser für SQL-Strings (=avoid using concenated Strings; use Parameters instead)

Also Zeug, dass eingefahrere Entwickler und Neulinge mit wichtigen Konzepten vertraut macht.

😃

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

Gelöschter Account
vor 13 Jahren

Please use using or Try-finally for Types implementing IDisposeable

Nicht immer sinnvoll und als Error schon gar nicht.

Also Zeug, dass eingefahrere Entwickler und Neulinge mit wichtigen Konzepten vertraut macht.

--> FxCop
Statische Codeanalysen sind ohnehin schon in VS2010 integriert. Und eingefahrene Entwickler lassen sich durch sowas nicht aus der Ruhe bringen 😄

X
1.177 Beiträge seit 2006
vor 13 Jahren

Na gut, dann wenigstens ne Warung^^

und "eingefahrene Entwickler" interessieren sich erst garnicht für FxCop; aber wieso nicht endlich mal ein paar [Obsolte] von Warning auf Error stellen?

Es mag möglich sein, in denen ein Dispose nicht aufgerufen werden "muss" - aber eine Situation in der es nicht aufgerufen werden soll?

😃

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

1.044 Beiträge seit 2008
vor 13 Jahren

Hallo Xynratron,

das wäre ein Fall für das ObsoleteAttribute oder für Code Contracts.

zero_x

6.862 Beiträge seit 2003
vor 13 Jahren

Hallo,

sowas sollte keinesfalls in den Compiler. Tools zur Codeanalyse wie FxCop sind genau der richtige Platz für sowas. Man muss immer an die ganzen Implikationen denken die so ein Feature bringt: Analyse kostet Zeit und grad bei großen Projekten kann das extrem nervig sein, grad wenn man das Feature nicht will, und man brauch sowas ja eh nicht bei jedem Compilevorgang. Dann lieber ne optionale Nachanalyse wie es jetzt schon möglich ist.

Baka wa shinanakya naoranai.

Mein XING Profil.

X
1.177 Beiträge seit 2006
vor 13 Jahren

huhu,

wenn es um Geschwindigkeit geht, dann könnte man gleich wieder alle Generics, Lamda, und Linq rauswerfen. Vermutlich noch ein paar Dinge mehr. Aber es geh ja nicht nur um den Compiler 😉 sondern um das Framework und eine Wunschliste.

Es würden ja tatsächlich ein [Obsolete] im Framework reichen - und manche alten Obsolete-Drohungen "Wird in zukünftigen Versionen nicht mehr zu Verfügung stehen" mal wahr werden zu lassen.
😃

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

Gelöschter Account
vor 13 Jahren

Es mag möglich sein, in denen ein Dispose nicht aufgerufen werden "muss" - aber eine Situation in der es nicht aufgerufen werden soll?

wenn ich z.b. eine Unmanaged Ressource verwende die 2 Sekunden zur Initialisierung benötigt aber nur nanosekunden für die aufrufe dannach. Dann macht es absolut keinen sinn, das ich ein using() oder try-finally verwende, wo ich dann jedesmal neu initialisieren muss...

X
1.177 Beiträge seit 2006
vor 13 Jahren

hmm, ja, guter Einwand 😃 - dem liese sich aber dann mit einem Compiler-Symbol beikommen - für diejenigen, welche wissen was sie tun.

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

Gelöschter Account
vor 13 Jahren

Das war nur ein Beispiel... es gibt da noch viel mehr. Eine narrensichere Sprache wirst du nicht finden und auch nicht designen können.

U
282 Beiträge seit 2008
vor 13 Jahren

Ich glaube, dass ich den Wunsch schonmal geschrieben habe und dass er eh nie kommen wird, weil es in den IL-Code rein muss.

Aber die größte Schwäche von Java und C# vgl. mit C++ ist meiner Meinung nach die fehlende const correctness

S
8.746 Beiträge seit 2005
vor 13 Jahren

Da müßtest du wohl erstmal Herrn Heijlsberg persönlich überzeugen, denn der denkt - wie ich finde zurecht:

The reason that const works in C++ is because you can cast it away

Angesichts solch grundlegender Abneigungen, scheinen technische Probleme wie Metadaten-const fast nebensächlich. Und wenn die Runtime const prüft, nutzt es eh keiner wegen der schlechten Performance.