IntelliSense und Erweiterungen von Klassen

IntelliSense in Visual Studio ist eine wunderbare Sache, die das Programmieren ungemein erleichtert. Eigentlich sollte heutzutage niemand mehr in einer Umgebung programmieren müssen, wo kein in etwa gleichwertiges Feature zur Verfügung steht. Trotzdem sahen wir ein ernstzunehmendes Problem damit, als wir hier in der Megos ernsthaft damit begannen, unsere neues Programmierwerkzeug Triton in C# zu implementieren.

IntelliSense scheint seine Listen immer stur alphabetisch zu sortieren und immer alles aufzulisten, ohne Filtermöglichkeiten. Das kann dan zu einem Problem werden, wenn man Klassen erweitert, die bereits eine Menge Members haben, und dann in der IntelliSense-Liste seine „eigenen“ Members (d.h. diejenigen der Erweiterung) kaum mehr findet. Je nach Art der Klassen benötigt man beim Implementieren bevorzugt eben diese eigenen Members, was das Ganze dann etwas mühsam macht.

Unsere Überlegungen zeigten uns, dass sich die Sache zuspitzt, wenn man Klassen für den Datenbank-Zugriff generiert, wo für jede Kolonne in einer Tabelle eine Property definiert wird, die sich dann zu all den Members der Zugriffs-Basisklasse gesellt und unter diesen irgendwie unterzugehen droht, obwohl sie doch zum eigentlichen „Witz“ der generierten Klasse gehört.

Man kann das bereits bei Visual-Studio-eigenen typed datasets beobachten: Eine Tabellen-Zugriffs-Klasse wird von System.Data.TypedTableBase abgeleitet, einer Klasse mit geschätzten etwa 100 Members. Eine Kolonne TitelKurs wird zu einer Property namens TitelKursColumn und wird von IntelliSense unter T eingeordnet; eine Kolonne WährungsKurs wird zu WährungsKursColumn und taucht dann in der Liste unter W und damit an einem ganz anderen Ort auf. Dieses Verhalten verunmöglicht es praktisch, sich per IntelliSense einen schnellen Überblick über alle Kolonnen zu verschaffen – aber wo ausser da soll denn dieser Überblick herkommen?

Es war schnell klar, dass es bei Visual Studio und IntelliSense, so wie jetzt implementiert, nur ein einziges „Rädchen“ gibt, an dem man überhaupt drehen kann, wenn man dieses Problem irgendwie lösen will: Will man Members zusammen sehen in einer IntelliSense-Liste, so müssen sie eben entsprechend heissen, d.h. alle mit irgendeinem Präfix beginnen.

Sie werden als geneigter Leser vielleicht schon ahnen, dass dieser Blog-Eintrag hier geradewegs auf ein Dilemma zumarschiert: Von Namenspräfixen wird in .NET und C# eigentlich abgeraten; verwendet man sie trotzdem, stecken einen gewisse Leute schnell einmal in die Schublade „Ewiggestrige“, die reserviert ist für Leute, die von ihren alten Gewohnheiten nicht lassen können und auch nicht verstanden haben, dass man heutzutage nur noch „natürliche“ Namen vergibt, weil man – eben gerade durch Features moderner IDEs wie z.B. IntelliSense – nicht mehr darauf angewiesen ist, vom Namen eines Dings irgendwelche Meta-Information ablesen zu können.

Aber wie gesagt, hier geht es nicht darum, sondern um eine Lösung für ein kleines, aber sehr lästiges Problem mit IntelliSense.

Wir sahen das Ganze als Wahl zwischen zwei Übeln: 1) einen Teil der Namen mit Hilfe von Präfixen verunstalten, aber damit den Nutzen von IntelliSense aufwerten, oder 2) den Empfehlungen und der Mehrheit der C#-Programmierer folgen, aber sich mit Situationen abfinden, in denen IntelliSense wenig hilft, obwohl es gerade da sehr nützlich wäre.

Nach einigem Hin und Her entschieden wir uns für das Übel 1). Wir wählten z.B. für die Properties unserer eigenen Klassen in Triton den Einbuchstaben-Präfix z, weil eine Abklärung ergab, dass nur wenige .NET-Klassen bereits Properties haben, mit mit Z beginnen, und damit diese Properties nicht nur zusammen angezeigt werden in einer IntelliSense-Liste, sondern auch noch herausstechen.

Seit dieser Entscheidung haben wir eine rechte Menge Code gemäss diesen Präfix-Konventionen erzeugt, und es ist eine erste Beurteilung des Erreichten möglich. Der gewünschte Effekt bei IntelliSense hat sich eingestellt: Man behält so tatsächlich ohne Probleme den Überblick über die eigenen Dinge im Gegensatz zu den „fremden“ Dingen des Frameworks. Aber hübsch sieht es irgendwie nicht aus, und eine richtige Gewöhnung an unsere mit Präfixen dekorierten Namen will sich eigentlich auch nicht einstellen.

Für jemanden, der sich im .NET-Framework wirklich gut auskennt, gäbe es vielleicht eine Wahlmöglichkeit 3), welche das Dilemma umgeht: ein Add-In programmieren, welches neben der IntelliSense-Liste eine zweite, entsprechend eingeschränkte Liste implementiert. Aber ganz soweit sind wir in der Megos noch nicht…

Advertisements
Veröffentlicht in Keine Kategorie. Schlagwörter: , . 1 Comment »

Die vielen Implementationen von .NET

Hat man sich erst mal mit Hilfe einer virtuellen Maschine im Prinzip von Betriebssystem und CPU-Architektur gelöst, wie das ja bei .NET und der CLR der Fall ist, ist man frei, diese virtuelle Maschine für ganz unterschiedliche Umgebungen zu implementieren. Und obwohl .NET noch ziemlich jung ist, kommen schon eine ganze Reihe von Implementationen zusammen. Ich habe mir für dieses Posting einmal einen aktuellen Überblick verschafft (allerdings ohne aufzuführen, welche Komponenten aus dem umfangreichen .NET-Technologie-„Baukasten“ denn genau wo zur Verfügung stehen):

Die allseits bekannte „Mutter“ aller .NET-Implementationen und dementsprechend relativ uninteressant für diese Auflistung ist diejenige von Microsoft selbst für die verschiedenen Windows-Varianten, die hier zu Hause ist.

Eine Spur interessanter ist das .NET Compact Framework, ebenfalls von Microsoft selbst, das auf PDAs und Smartphones mit Windows Mobile läuft. Interessant, wie viel vom „grossen“ Bruder es in die Kompakt-Variante schafft.

Es geht aber noch kleiner als Smartphones: Mit dem .NET Micro Framework versucht Microsoft, selbst Geräte mit stark limitiertem Speicher abzudecken, wie z.B. ihre experimentelle SPOT Armbanduhr zeigt.

Es ist mir nicht klar, ob die Shared Source Common Language Infrastructure, früher mit Rotor als Codename und in der Wikipedia hier beschrieben, eine zweite .NET-Implementation von Microsoft darstellt, oder nur eine neue Zusammenstellung einer einzigen Implementation, oder etwas dazwischen, aber interessant ist, dass frühe Versionen offenbar neben Windows auch auf FreeBSD und Mac OS X lauffähig waren.

Wer sich auch nur ein wenig dafür interessiert, wie die Welt ausserhalb von Microsoft aussieht, kennt sicher mittlerweile Mono, ein sehr erfolgreiches Projekt, welches es einem ermöglicht, seine .NET-Programme auch auf Linux und Mac OS X laufen zu lassen. Man kann offenbar, wie hier beschrieben, dank einem Hack Mono sogar verwenden, um Programme für das Compact Framework herzustellen, muss aber selbst aufpassen, nichts zu verwenden, was da nicht vorhanden ist.

Schon weniger bekannt dürfte sein, dass Mono im Bereich Open Source Konkurrenz hat in Form des DotGNU-Projekts. Ohne das Projekt im Detail zu kennen, bekam ich beim Studium der Website allerdings den Eindruck, dass hier im Moment um einiges kleinere Brötchen gebacken werden als bei Mono, und es scheint mit einem Motto GNU Freedom for the Net und Statements wie etwa Don’t get caught in a .Net auch stärker um ideologische Fragen zu gehen als bei der Konkurrenz.

Einen grossen Schub in Sachen Verbreitung könnte .NET erfahren, wenn es als Basistechnologie für Silverlight in der Version 2 den Weg in die Internet-Browser dieser Welt schafft. Microsoft will mit Silverlight 2 bereits selber eine Reihe von Plattformen abdecken, und das Mono-Pendant Moonlight will für eine nochmals grössere Reichweite sorgen. Wie erfolgreich die Sache wirklich wird, scheint mir im Moment noch etwas in den Sternen zu stehen, aber zumindest die Technologie sieht sehr solide aus.

Und jetzt wird es etwas exotisch: Die Firma Red Five Labs aus Südafrika hat, soweit erkennbar vollständig aus eigener Kraft, das .NET Compact Framework für Symbian/S60-basierte Smartphones implementiert. Wenn jetzt nur noch das Geld da wäre für eine ordentliche Werbekampagne, um dieses Produkt unter den Entwicklern auch bekannt zu machen… Und wie es damit weitergeht, wenn Silverlight 2 wie geplant ebenfalls auf S60 ankommt, ist eine offene Frage.

Wenn man mehr spielerisch veranlangt ist, kann man seine C#- und .NET-Kenntnisse auch dadurch erwerben, dass man mit Hilfe von XNA Spiele für die Xbox 360 programmiert. Sogar eine Unterstützung von Zune Players ist offenbar in der Pipeline.

Und zum Schluss noch dies: Unter dem Namen CrossNet hat offenbar jemand einen sehr speziellen CIL-Decompiler geschrieben, der Standard-C++-Code auswirft, den man dann fast überall kompilieren kann. Das ist für den eigenen Code ganz schön; das grosse und offenbar weitgehend ungelöste Problem scheint zu sein, wie man am „neuen Ort“ zu einer .NET Base Class Library, sprich zu einem „Framework“, kommt.

Veröffentlicht in Keine Kategorie. Schlagwörter: . 2 Comments »