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
Hallo pdelvo,
ich fänd's sehr cool, wenn die Möglichkeiten von Spec# in C# übergehen würden. 😃
Grüße,
Isaac
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!"
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
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."
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
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
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
}
}
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
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
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
Hallo Peter Bucher,
interessant in dem Zusammenhang ist vor allem das Konzept Design by contract (Deutsch) / Design by contract (Englisch).
Grüße,
Isaac
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
zero_x | <span style="font-size: 10;">my</span><span style="font-size: 10;">CSharp</span><span style="font-size: 10;">.de</span> - gemeinsam mehr erreichen
Für längere Zeit inaktiv.
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!"
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
zero_x | <span style="font-size: 10;">my</span><span style="font-size: 10;">CSharp</span><span style="font-size: 10;">.de</span> - gemeinsam mehr erreichen
Für längere Zeit inaktiv.
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.
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
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
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!"
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
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
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!"
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
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!"
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
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...
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.
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
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. 😉
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!"
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.
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!"
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
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!"
Mal ein paar Anmerkungen zu den Vorschlägen:
Was ich gerne hätte:
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
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
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
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]
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.
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
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";
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!"
bisher kann man (vermutlich) alles was hier ist irgendwie selber basteln - darum gehts aber nicht sondern das es per default schon fertig dabei ist
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!"
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.
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 😉
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
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^^.
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!"
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
Das ist das, was ich mit dem oben erwähnten IArithmetic meinte ...
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden