Laden...

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

Erstellt von pdelvo vor 14 Jahren Letzter Beitrag vor 13 Jahren 43.308 Views
pdelvo Themenstarter:in
1.346 Beiträge seit 2008
vor 14 Jahren
Was wünscht ihr euch für C# 5?

C#4 steht vor der Tür, nun wollte ich mal in die Zukunft guken und mal fragen, was ihr euch für C# 5 wünschen würdet?

Ich fange mal in. Inline ILASM. Das wäre echt eine erleichterung. Bei manchen sachen muss man echt einen umweg machen(zB viele variablen erzeugen, etc). Das kann man an manchen Stellen echt verkürzen, wenn man es selber macht.

Mal ein konkretes Beispiel:


//'Altes' C#
int i = 6;
int j = 3;
int z = i;
i = j;
j = z

//'Neuses' C#
int i = 6;
int j = 5;
IL
{
push i
push j
pop i
pop j
}

Was fällt euch so ein?

Gruß pdelvo

U
208 Beiträge seit 2008
vor 14 Jahren

Hallo pdelvo,

ich fänd's sehr cool, wenn die Möglichkeiten von Spec# in C# übergehen würden. 😃

Grüße,

Isaac

6.911 Beiträge seit 2009
vor 14 Jahren

Hallo,

die Frage überrascht mich ein wenig, aber was mir spontan einfällt:*Bei automatic Properties sollte es möglich sein Default-Werte zu setzen (zB via Attribute und der Compiler generiert den Code dazu) *Bei Verwendung von INotifyPropertyChanged sollte der Compiler den Namen (der als String übergeben werden muss) automatisch ableiten. *Generische Serialisation. Damit meine ich dass v.a. die Deserialize-Methode gleich den richtigen Typ zuückgibt ohne einen cast durchführen zu müssen. *Mehr Unterstützung für numerische Berechnungen (Array-Slicing, Matrix-Operationen, ...)

Mehr fällt mir sicher ein wenn ich mich mal ärgere warum es dies oder jenes nicht gibt.

Man kann sich für das alles zwar selbst Hilfsklassen/Methoden schreiben, aber wenn es von Haus aus dabei wäre könnte jeder in diesen Genuss kommen.

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!"

3.430 Beiträge seit 2007
vor 14 Jahren

Hallo,

hm, also ich bin momentan ziemlich glücklich wie es ist.
Aber eine Funktion die mir zu den schon genannten noch als praktisch erscheint ist ein spezielles Property das schon von sich aus NotifyPropertyChanged aufruft.

So ist es momentan


private string _myProperty;

public string MyProperty
{
   get{ return _myProperty;}
   set
   {
      _myProperty=value;
      if(PropertyChanged!=null)
        PopertyChanged(this, new PropertyChangedEventArgs("MyProperty));
}

so wäre es ganz nett 😃


public NotifyPropertyChanged string MyProperty{get;set;}

Über die Syntax kann man natürlich streiten aber so etwas wäre doch praktisch.
Denn oft muss man die Fields machen nur um das PropertyChanged auslösen zu können wenn der Wert geändert wird.
Und gerade wie schon gfoidl gesagt hat ist es dann noch das Problem mit dem Namen.
Da schleichen sich schnell mal Fehler ein und es ist viel (teils unnötige) Tipparbeit.

Gruss
Michael

C
114 Beiträge seit 2008
vor 14 Jahren

Hi,

Ich bin ansich auch ziemlich zufrieden mit C#. Was mich persönlich stört, ist die Geschwindigkeit. Es gibt einfach Dinge, die man in C# nicht anzufangen braucht, weil es nie schnell genug sein wird. Da wäre im Endeffekt warscheinlich nur ein AOT Native Compiler die richtige Lösung. Aber ich greife so unglaublich ungerne zu C++, weil C# einfach viel schöner ist. Naja, evtl. ist es da tatsächlich eine Möglichkeit direkt in ILASM schreiben zu können. Unter Linux geht das übrigens schon, zumindest habe ich das in MonoDevelop oder Anjuta (weiß grade nichmehr welches es war) gesehn.

Greetz, der Hühneradel

„Heute back ich, morgen brau ich,
übermorgen cast ich die Königin nach int;
ach, wie gut dass niemand weiß,
dass ich Rumpelstilzchen heiß!“

"Bei Stylefragen sollteste nen Mac-User oder ne Frau fragen."

390 Beiträge seit 2008
vor 14 Jahren

Properties/Member als Referenzen übergeben!


class Program 
  {
    static void Main(string[] args) 
    {
      MyClass foo = new MyClass();

      MyFunc(ref foo.Bar);

      Console.WriteLine(foo.Bar); //23
    }

    static void MyFunc(ref int val) 
    {
      //...
      val = 23;
    }
  }


  class MyClass 
  {
    private int bar;

    public int Bar 
    {
      get { return bar; }
      set { bar = value; }
    }
  }

using Skill

1.002 Beiträge seit 2007
vor 14 Jahren

Hallo,

folgendes Compilerfeature für foreach-Schleifen wäre sehr nützlich:

foreach (var item in collection)
{
    first
    {
        // Nur ausführen, wenn erstes Element
    }
    
    medial
    {
        // Nur ausführen, wenn weder erstes noch letztes Element
    }

    last
    {
        // Nur ausführen, wenn letztes Element
    }
}

m0rius

Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg

C
401 Beiträge seit 2007
vor 14 Jahren

Ich würde gerne ein Konstrukt aus D sehen und zwar die Pre- und Post-Contracts. Das sieht folgendermaßen aus:


int MyMethod(int a, int b)
{
  in
  {
    // check input values
  }
  out(result)
  {
    // check return value
  }
  body
  {
    // do sth
  }
}

2.891 Beiträge seit 2004
vor 14 Jahren

Hallo zusammen,

ich würde ja - als Gegensatz zu Werttypen, die auch null sein können (Nullables) - Referenztypen, die nicht null sein dürfen, schön finden (wie z.B. in Spec#).


void Main(int? nullableInt, Uri! nonNullableUri)
{ }

Gruß,
dN!3L

1.002 Beiträge seit 2007
vor 14 Jahren

Hallo dN13L,

oh ja, dieses Feature wäre wirklich super.

m0rius

Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg

5.941 Beiträge seit 2005
vor 14 Jahren

Hallo dN!3L

Ich wüsste nicht wozu das nützlich sein könnte.
Oder verstehe ich das falsch und wäre das eine Condition für den Methodenaufrufer?

Ansonsten würde mich der Nutzen interessieren?

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

U
208 Beiträge seit 2008
vor 14 Jahren

Hallo Peter Bucher,

interessant in dem Zusammenhang ist vor allem das Konzept Design by contract (Deutsch) / Design by contract (Englisch).

Grüße,

Isaac

1.044 Beiträge seit 2008
vor 14 Jahren

Hallo zusammen,

was ich mir wünsche, wäre einerseits ein bessere Unterschützung in Visual Studio für LINQ to XML und das es inline-Assembler in C# gibt. In Visual Basic lässt sich z.B. folgendes machen:

Dim xml = <root>
                <child>myCSharp!</child>
          </root>

zero_x

6.911 Beiträge seit 2009
vor 14 Jahren

inline-Assembler in C#

Ich weiß ehrlich gesagt nicht für was das gut sein sollte. Sämtliche "Optimierungen" die damit möglich sein sollten sind nicht vergleichbar mit zB Inline-Asm in C++. Der IL-Code muss ja sowieso geJITet werden und dort werden wenn es die Heuristik des JITer zulässt optimiert. Ein möglicher Ansatzpunkt wären einige Direktiven um den JITer bei den Optimierungen zu untersützen (die zB das Inlinen erlauben). AFAIK wurde das aber von MS schon mehrmals diskutiert und sie fanden bisher immer Gründe warum das verworfen wurde.

Wo wäre der Vorteil von Inline-IL in C#?

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 14 Jahren

Hallo gfoidl,

Wo wäre der Vorteil von Inline-IL in C#?

Damit meine ich richtigen Assembler-Code. Das hätte z.B. den Vorteil, dass man in C# einen API-Hook programmieren könnte. Möchte man in C# einen API-Hook verwenden, kann man das leider nur mit separten nicht-.NET DLLs umsetzen.

zero_x

1.130 Beiträge seit 2007
vor 14 Jahren

m0rius Vorschlag hab ich asuch schon vermisst. Ansonsten Wäre es nett, wenn arrays sämtliche Stringoperationen mit delegatenparameter (anonyme methoden) unterstützen würden: split, IndexOf, LastIndexOf...

Inline-Assember wünsche ich mir auch.

Für Notify-Propertys würde ja auch eine automatische Codegenerierung im VS reichen.

Projekte:Jade, HttpSaver
Zum Rechtschreiben gibts doch schon die Politiker. Aber die bauen auch nur mist!

5.941 Beiträge seit 2005
vor 14 Jahren

Hallo zusammen

@Isaac
Was meine Frage leider nicht beanwortet.

@zero_x
Das hat überhaupt nichts mit LINQ To Xml zu tun.
Ausserdem geht es doch mit C# relativ einfach, häufig und viel sollte sowas sowieso nicht eingesetzt werden.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

2.891 Beiträge seit 2004
vor 14 Jahren

Hallo Peter,

Oder verstehe ich das falsch und wäre das eine Condition für den Methodenaufrufer?

Wie hast du es denn verstanden? 😉
Wie Issac (und du) schon schrieb, primärer Anwendungsfall wäre ein Kontract z.B. für eine Methode, dass ein Parameter nie null ist/sein darf. Ebenso anwendbar z.B. bei Properties oder Klasseninvarianten.
Im Prinzip wäre es eine Kurzschreibweise für eine bestimmte Art von Kontrakten.

Gruß,
dN!3L

6.911 Beiträge seit 2009
vor 14 Jahren

Das hätte z.B. den Vorteil, dass man in C# einen API-Hook programmieren könnte.

Das ist aber voll gegen den Sinn von .net.

Für Notify-Propertys würde ja auch eine automatische Codegenerierung im VS reichen.

Besser wäre es wenn der Compiler den Code generiert.

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!"

57 Beiträge seit 2009
vor 14 Jahren

Hallo gfoidl,

wie würdest Du folgendes Problem lösen: Der Kunde hat ein englisches XP, möchte aber eine deutsche UI-Culture. Und selbstverständlich soll dann auch die OS-MessageBox auf deutsch erscheinen.

Gruß
Assri Komla

5.941 Beiträge seit 2005
vor 14 Jahren

Salute dN!3L

Wie hast du es denn verstanden? 😉

Ich habe gedacht das ihr nicht Nullable Referenztypen wollt, worin ich keinen Sinn sehe.

Aber als eine Schreibweise für Conditions ist natürlich was anderes 😃.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

6.911 Beiträge seit 2009
vor 14 Jahren

wie würdest Du folgendes Problem lösen

Gar nicht 😉.
Wenn davon ausgegangen werden kann dass .net "plattformunabhängig" sein soll/te dann sind solche Lösungen sowieso nicht möglich.
Außerdem wird mit C++/CLI diese Möglichkeit angeboten. Für C# sehe ich darin keinen Sinn.

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!"

57 Beiträge seit 2009
vor 14 Jahren

Hallo gfoidl,

mit 'plattformunabhängig' meint MS nur die eigenen Betriebssysteme, von denen die betagteren bekanntermaßen auch nur eine Untermenge der .NET-Frameworks unterstützen. Nur das hat mit dem von mir formulierten Problem rein gar nichts zu tun. Da ist im Falle der MessageBox einzig und allein vom Win32API die Rede.

Ebenso wenig hat das etwas mit C# oder C++/CLI zu tun. Wir unterhalten uns hier über PInvoke und die von Dir so gescholtenen Hooks. Das war der Grund, weshalb ich Dir diese Frage gestellt habe.

Und: Ja, das Problem ist lösbar. Und zwar sehr elegant.

Gruß
Assri Komla

6.911 Beiträge seit 2009
vor 14 Jahren

Ebenso wenig hat das etwas mit C# oder C++/CLI zu tun. Wir unterhalten uns hier über PInvoke

Ich unterhalte mich über C# 5.0 😉

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!"

5.941 Beiträge seit 2005
vor 14 Jahren

Hallo Assri Komla

Und: Ja, das Problem ist lösbar. Und zwar sehr elegant.

Und: Ja, du kannst es spannend machen. Und zwar sehr elegant.

😉

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

S
8.746 Beiträge seit 2005
vor 14 Jahren

Ich behaupte: 90% aller Entwickler machen im Prinzip nur C# 2.0. Deswegen ist es völlig Wurscht wie C# 5.0 aussieht: Es benutzt eh kaum jemand.

Manchmal ist weniger auch mehr...

799 Beiträge seit 2007
vor 14 Jahren

Ich behaupte: 90% aller Entwickler machen im Prinzip nur C# 2.0. Deswegen ist es völlig Wurscht wie C# 5.0 aussieht: Es benutzt eh kaum jemand.

Manchmal ist weniger auch mehr...

Full Ack

As a man thinketh in his heart, so he is.

  • Jun Fan
    Es gibt nichts Gutes, außer man tut es.
  • Erich Kästner
    Krawutzi-Kaputzi
  • Kasperl
pdelvo Themenstarter:in
1.346 Beiträge seit 2008
vor 14 Jahren

Ich finde nicht, dass man auf einer alten Version sitzen bleiben muss. Damit würde man den Fortschritt anhalten bzw. ausbremsen und C# würde im laufe der Zeit unaktraktiver werden.

Gruß pdelvo

5.742 Beiträge seit 2007
vor 14 Jahren

Hallo zusammen,

Spec#-Konstrukte würde ich auch sehr gerne in C# sehen.

Außerdem wäre Unterstützung eines "Implies"-Operators (a -> b statt !a || b) interessant.

Auch read-only-Automatic Properties wären ganz nett.

Dann noch eine kleine Erweiterung des typeof Operators, sodass dieser direkt PropertyInfos etc. liefern kann und abschließend direkte Unterstützung von WeakEvents durch weak event und C# 5.0 ist für mich komplett. 😉

6.911 Beiträge seit 2009
vor 14 Jahren

Hallo winSharp93,

Auch read-only-Automatic Properties wären ganz nett.

falls ich das richtig verstanden habe ist das machbar.


public int Value{get; private set;}

Oder meinst du was anderes?

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!"

5.742 Beiträge seit 2007
vor 14 Jahren

Oder meinst du was anderes?

Ja:


public int Foo
{
    get;
    readonly set; //bzw. private readonly set;
}

Somit kann man Foo dann nur im Konstruktor einen Wert zuweisen.

6.911 Beiträge seit 2009
vor 14 Jahren

Hallo winSharp93,

hast recht, dass wäre nützlich für immutable Objekte.

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.002 Beiträge seit 2007
vor 14 Jahren

Hallo winSharp93,

hmm. Ohne je versucht zu haben, dein Konstrukt zu verwenden, hätte ich vermutet, dass es funktioniert. Gerade für Immutables wäre es sicherlich sinnvoll ...

Edit: Argh, etwas zu langsam 😄.

m0rius

Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg

6.911 Beiträge seit 2009
vor 14 Jahren

Ohne je versucht zu haben, dein Konstrukt zu verwenden, hätte ich vermutet, dass es funktioniert.

Geht leider nicht. Musste ich auch gleich probieren 😉

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!"

4.207 Beiträge seit 2003
vor 14 Jahren

Mal ein paar Anmerkungen zu den Vorschlägen:

Was ich gerne hätte:

  • Statische Member und Konstruktoren in Interfaces
  • Parametrisierbare Properties
  • IArithmetic-Interface, um arithmetische Operationen auf Generics zu erlauben (okay, hat mehr was mit .NET als mit C# zu tun)

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

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

pdelvo Themenstarter:in
1.346 Beiträge seit 2008
vor 14 Jahren

Ich weiß, dass Inline MSIL schon über umwege geht. Wenn ich den Quellcode aber weitergeben möchte, funktioniert er nur, wenn der andere das tool auch hat. Ist also eine eher schlechte Lösung. Besser wäre was eingebautes.

Gruß pdelvo

3.430 Beiträge seit 2007
vor 14 Jahren

Hallo Golo,

Readonly automatically implemented properties: Geht auch schon indirekt, indem man den setter private macht

naja aber dann ist es trotzdem noch nicht readonly 😃

somit wäre es technisch gesehen ja nur das hier. Aber readonly wäre das noch lange nicht


private string _str;

public string Str
{
get{return _str;}
}

Gruss
Michael

Hinweis von herbivore vor 12 Jahren

Drei Seiten weiter hinten, hat AlexanderT am 30.10.2009 12:28 einen Beitrag gepostet, der sich auf diesen Beitrag bezieht. Weil durch den großen Abstand AlexanderTs Beitrag sehr verloren herumstand, habe ich den Modhinweis dazu genutzt, um den Beitrag hier her zu "verschieben":

könnte man nicht einfach:

[csharp]
readonly private int mypropertysetter = 3;

        public int MyProperty
        {
            get;
            private set
            {
                MyProperty = mypropertysetter;
            }
        }
[/csharp]

oder liege ich da Falsch?

Edit:

oder natürlich eher so hier:

[csharp]
        readonly private int mypropertysetter = 3;

        public int MyProperty
        {
            get
            {
                return mypropertysetter;
            }
        }
[/csharp]
6.862 Beiträge seit 2003
vor 14 Jahren

Hallo,

ich hab zwar selber grad wenig eigene Vorstellungen über mögliche Erweiterungen, aber viele von den hier genannten kann ich nicht gut heißen.

Z.b. ist ja INotifyPropertyChanged oft genannt worden. Das ist nen schönes Interface aber mehr auch nicht Es ist Teil eines ChangeNotification Patterns was sich entwickelt hat in der Klassenbibliothek. Klar braucht man das häufiger, aber wegen sowas würd ich den Compiler net aufblasen. Das ist nur die denkbar primitivste Art der ChangeNotification. In WPF sind z.B. die DependencyProperties hinzugekommen wo kein INotifyPropertyChanged gebraucht wird und deren ChangeNotification viel mächtiger ist. Genauso gut kann es auch noch weitere Konzepte zur ChangeNotification geben die irgendwann in Mode kommen. Sowas in der Sprache zu verankern obwohl es Teil der Klassenbibliothek ist, halte ich für wenig sinnvoll.

Oder die von Golo genannten statischen Member in einem Interface. Welchen Sinn siehst du darin? Geht es darum gemeinsame Daten zwischen den Implementierungen zu teilen? Die Idee verstehe ich, aber warum statisch? Das schreit doch nach Seiteneffekten ohne Ende wenn ich als Entwickler z.B. nen kleines Framework mir bastle und mein Interface an vielen Stellen verwende und ich net dran denk das von irgendwo im Code ne Variable geändert werden kann, da die statische Variable ja nur einmal für alle Instanzen existiert.

Baka wa shinanakya naoranai.

Mein XING Profil.

5.941 Beiträge seit 2005
vor 14 Jahren

Hoi Golo

  • Statische Member und Konstruktoren in Interfaces

Hatten wir da nicht mal einen Thread im Forum, warum das keinen Sinn macht?

  • Parametrisierbare Properties

Wie meinst du das genau?
Sowas?


public string Name(string prefix)
{
    get { return string.Concat(prefix, _name); }
    set { _name = value; }
}

Irgendwie sehe ich auch darin nicht wirklich einen Sinn oder ich meine das falsche.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

U
1.578 Beiträge seit 2009
vor 14 Jahren

ich vermute eher sowas:


public string Setting(string property)
{
    get { return _dic[property]; }
    set { _dic[property] = value; }
}

string serverIp = settings.Setting("Server");
settings.Setting("Server") = "192.100.0.1";

6.911 Beiträge seit 2009
vor 14 Jahren

Hallo,

ich vermute eher sowas:

das lässt sich allerdings über einen Indexer realisieren und diese können auch überladen werden.

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!"

U
1.578 Beiträge seit 2009
vor 14 Jahren

bisher kann man (vermutlich) alles was hier ist irgendwie selber basteln - darum gehts aber nicht sondern das es per default schon fertig dabei ist

6.911 Beiträge seit 2009
vor 14 Jahren

darum gehts aber nicht sondern das es per default schon fertig dabei ist

Ja das weiß ich. Indexer gibt es aber schon seit Urzeiten in .net. Wäre als nicht neues.

Bin mal auf Golos Vorstellung gespannt.

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!"

S
8.746 Beiträge seit 2005
vor 14 Jahren

VB.NET (und auch COM) kann das. C# kennt eben nur einen Indexer. Selbst Überladung hilft da nicht, denn ich kann ja verschiedene Properties haben wollen, deren Signatur gleich ist. Bei COM-Wrappern merkt man diesen Mangel manchmal, wenn man Getter/Setter-Funktionen findet. Einer fehlt dann meist: Der ist als Indexer umgesetzt.

5.742 Beiträge seit 2007
vor 14 Jahren

Contracts aus Spec#: Kommt in Form der Code Contracts mit VS2010

Nein, die Code Contracts sind nun doch nicht in VS 2010 integriert - die kommen als separater Download.
Außerdem verlassen sie sich auf statische Methoden und nicht auf Sprachkonstrukte. Das ist IMHO ein sehr entscheidender Unterschied.

Oder die von Golo genannten statischen Member in einem Interface.

Im Moment hätte ich dieses Feature auch sehr gerne, da ich (auch zwecks INotifyPropertyChanged 🙂 ) eine Klasse Property verwende - bei interfaces muss ich die entsprechenden Properties dann immer in einer Hilfsklasse platzieren.

ich vermute eher sowas:

Wenn, dann aber doch bitte eckige Klammern 😉

4.207 Beiträge seit 2003
vor 14 Jahren

Zum Thema "Parametrisierbare Properties": Im Endeffekt so was wie die Indexer, nur dass ich davon gerne mehrere hätte, und die nicht zwingend this nennen möchte - in VB geht das, in C# nicht.

Statische Member bzw Konstruktoren in Interfaces: Ich würde gerne zB in einem Interface vorgeben können, dass jede Klasse, die dieses Interface implementiert, einen bestimmten Konstruktor aufweisen muss - zum Beispiel einen Konstruktor mit einem bestimmen Parameter.

Analog dazu würde ich gerne erzwingen können, dass jede Klasse, die ein bestimmtes Interface implementiert, einen bestimmten statischen Member aufweisen muss.

Mir ist klar, dass Interfaces dafür der falsche Ort sind (@ Peter, ja dazu gab es auch schon mal eine Diskussion 😉), aber vom Prinzip her drückt es das aus, was mir fehlt: So eine Art Klassentemplate, das von abgeleiteten Klassen implementiert werden muss, was allerdings - im gegensatz zu Interfaces - von der Vererbung ausgenommen ist.

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

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

1.130 Beiträge seit 2007
vor 14 Jahren

Was mir fehlt sind Delegaten auf Konstruktoren. Man kann sich natürlich statische Methoden bauen, aber direkt wärs schöner.

Zum Thema Klassentemplate: Ich vermisse sowas auch.
Man kann sich natürlich eine Hilfsklasse basteln, die mit Reflektion automatisch delegates an die statischen Methoden einer Klasse bindet, aber das ist auch ned wirklich optimal.

Parameterisierbare Properties: wäre nützlich. Es darf aber nicht die Möglichkeit geben, gleichzeitig eine Parameterlose und Paramterisierte Überladungen anzubieten, da es sonst syntaktisches Chaos geben würde, da der Rückgabetyp ein this[] Propertie haben kann. Ok - Man könnte für solche Fälle auch die Schreibweise [] einführen^^.

Projekte:Jade, HttpSaver
Zum Rechtschreiben gibts doch schon die Politiker. Aber die bauen auch nur mist!

6.911 Beiträge seit 2009
vor 14 Jahren

Hallo,

was mich gerade etwas ärgert und deshalb wünsche ich mir:

Wenn ich ein static readonly Feld habe und das mit dem ThreadStatic-Attribut versehe dann sollte in den Threads bereits der Wert vorhanden sein.

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!"

2.891 Beiträge seit 2004
vor 14 Jahren

Gerade ist mir wieder was aufgefallen, was ich schmerzlich vermisse:
Angabe von Operatoren bei den Typeinschränkungen von Generika.


public void Add<T>(T left,T right) where T : T+T
{
   return left + right;
}

Gruß,
dN!3L

4.207 Beiträge seit 2003
vor 14 Jahren

Das ist das, was ich mit dem oben erwähnten IArithmetic meinte ...

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

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