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
}
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.
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ß!“
Zitat
"Bei Stylefragen sollteste nen Mac-User oder ne Frau fragen."
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; }
}
}
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
}
}
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#).
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:
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!"
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.
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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Floste am .
Projekte:Jade, HttpSaver
Zum Rechtschreiben gibts doch schon die Politiker. Aber die bauen auch nur mist!
@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
- https://peterbucher.ch/ - Meine persönliche Seite
- https://fpvspots.net/ - Spots für FPV Dronenflüge
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.
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.
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!"
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.
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.
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.
