Im Artikel zur impliziten Typisierung hatte ich bereits auf einen späteren Artikel zum Thema dynamische Typisierung verwiesen, was mit diesem Beitrag nun auch erfolgen soll.

Seit .NET 4.0 enthält das Framework die sog. Dynamic Language Runtime, was sich bei C# auf den ersten Blick durch das neue Schlüsselwort dynamic, die Basisklasse DynamicObject und das ExpandoObject mit entsprechender Funktionalität bemerkbar macht.

Die DLR ermöglicht zwar "auch" interessante Aspekte im Hinblick auf die Integration dynamisch typisierter Programmiersprachen wie beispielsweise Python (→ IronPython) oder Ruby (→ IronRuby) in das .NET-Framework, ich möchte in diesem Beitrag aber dennoch bei den Möglichkeiten in C# selbst bleiben. Ein paar Gedanken meinerseits zur Typisierung im Allgemeinen sollen in einem späteren Beitrag folgen.

Wie vielen Lesern dieses Blogs bekannt sein dürfte, handelt es sich bei C# um eine grundsätzlich statisch typisierte Programmiersprache, d. h. die Typen aller Variablen sind bereits zum Zeitpunkt der Kompilierung bekannt, was nicht zuletzt auch ermöglicht, dass euch Visual Studio hilfreiche Hinweise schon während der Entwicklung geben kann.

Durch die DLR wird von diesem Prinzip (glücklicherweise ) nicht grundsätzlich abgewichen, jedoch stellt sich euch die Möglichkeit, von diesem Vorgehen explizit abzuweichen, indem ihr als Typ dynamic deklariert. Dadurch wird die statische Typprüfung deaktiviert und auf die Laufzeit verschoben. Das bedeutet, dass ihr einer Variable dieses Typs beliebige – also auch gar nicht existente – Eigenschaften zuweisen oder darauf Methoden aufrufen könnt, im Problemfall jedoch zur Laufzeit eine entsprechende Ausnahme erhaltet.

Wir beginnen – wie üblich – mit einem kleinen Code-Beispiel zur Verdeutlichung: Nun können wir relativ "normal" damit arbeiten, beispielsweise die Werte in einer MessageBox ausgeben: Soweit hätte das natürlich auch ohne dynamic funktioniert, der interessante Aspekt ist jedoch, dass sich beispielsweise auch folgender Code kompilieren lässt – Visual Studio zeigt euch bei Eingabe des Punktes (→ IntelliSense) nur mehr "(dynamischer Ausdruck) Der Vorgang wird zur Laufzeit aufgelöst." an: Ohne dynamic hätte euch Visual Studio bereits während der Entwicklung angezeigt, dass Replace(…) für den Datentyp int nicht zur Verfügung steht (bzw. erst gar nicht zur Auswahl angeboten) und die Kompilierung mit einem Fehler abgebrochen.

Im Gegensatz zu var kann sich der Typ unserer Variable nun auch während der Laufzeit ändern: Dies entspricht schon sehr dem Verhalten, wie man es von Sprachen wie PHP kennt und bringt die entsprechenden Vorteile, aber eben auch gravierende Nachteile mit sich. Ob eine Operation zu Problemen führt, erkennt man nunmehr erst zur Laufzeit – und mit etwas Pech auch nicht sofort, da die ungültige Operation möglicherweise nicht sofort zur Verwendung kommt, mit statischer Typisierung aber dennoch bereits zur Entwicklungszeit von Visual Studio darauf hingewiesen worden wäre, dass dies niemals möglich sein wird.

Wenn das nun neben ein bisschen Bequemlichkeit beim Tippen doch eher Probleme einführt, stellt sich natürlich die berechtigte Frage, wozu man so etwas verwenden sollte. Hauptsächlich handelt es sich tatsächlich um ein Mittel, dynamische Sprachen in das .NET-Framework zu integrieren, welche nun einmal auf diesem Konstrukt basieren. Auch die Verwendung entsprechender Programmbibliotheken, um beispielsweise einfach über XML-Knoten zu navigieren (man denke an dieser Stelle auch an das DOM) sind sicherlich eine praktikable Idee. Für die reine Bequemlichkeit ist implizite Typisierung jedoch definitiv besser geeignet.

Ich würde auf jeden Fall dringend davon abraten, unter C# selbst exzessiven und vor allem unüberlegten Einsatz davon zu machen. Natürlich kann man sich dadurch z. B. gewisse Umstände, die Reflektion mit sich bringt, ersparen, dennoch würde ich hier nach wie vor zu einem sauberen, auf Schnittstellen basierten Modell raten. Dadurch, das alles "irgendwie" aufgerufen werden kann, handelt man sich nicht selten schwer auffindbare und auch lösbare Fehler ein. Insbesondere sollte bedacht werden, dass das .NET-Framework beim Aufruf entsprechender Funktionalität auch immer passende Datentypen erwartet; Folgendes ergibt beispielsweise umgehend einen Laufzeitfehler: Das Problem ist nämlich, dass Show(…) eine Zeichenkette erwartet; bei b hätte es auch so funktioniert, c muss jedoch zwingend mit ToString() aufgerufen werden. Mit statischer Typprüfung sind das alles Probleme, die man bereits beim Schreiben des Quelltextes erfährt. Mit dynamischer Typprüfung möglicherweise aber erst nach einigen Stunden oder gar noch längerer Laufzeit, wenn die Stelle zum ersten Mal zur Ausführung kommt.

Da wir nun umfassend auf die potentiellen Gefahren eingegangen sind und erste Beispiele betrachtet haben, möchte ich noch einmal kurz auf DynamicObject und ExpandoObject zurückkommen und dazu jeweils ein kleines Anwendungsbeispiel demonstrieren. Wir beginnen mit dem ganz einfachen ExpandoObject und fügen diesem Eigenschaften und Verhalten hinzu: Als nächstes wollen wir noch einen (kleinen) Blick auf das DynamicObject werfen, von welchem wir erben und dabei spezifisches Verhalten für bestimmte Aktionen festlegen können. Konkret möchten wir den Zugriff auf Eigenschaften unabhängig von Groß-/Kleinschreibung ermöglichen: Mein Fazit: Sicherlich wünscht man sich das eine oder andere Mal während der Entwicklung ein wenig mehr Dynamik, aber dafür bezahlt man einen nicht unerheblichen Preis zum Nachteil der Wartbarkeit. Zur Implementierung von Standardaufgaben sollte das unter C# nicht das erste Mittel der Wahl sein, eher eines der letzten – C# bietet hier für gewöhnlich mächtige und vor allem typsichere Alternativen. Ja, das ist durchaus mit etwas mehr Schreibarbeit verbunden.

Wie üblich hält das MSDN weitere Hinweise zur Verwendung parat.

Zu meinem letzten Eintrag hat mich eine Mischung aus Frage und Idee erreicht, dieses Verfahren doch auch bei Versionskennungen (z. B. v1.2.3) anzuwenden, welche schließlich ähnlich aussehen, wie eine IP-Adresse.

Grundsätzlich ist das natürlich naheliegend und nicht völlig abwegig, funktioniert jedoch nur bedingt. Das Problem: Die Ziffern unserer Stellen müssten nach bisherigem Vorgehen endlich sein, damit wir die Basis korrekt wählen können, um das Ergebnis eindeutig zu halten. Im Dezimalsystem stehen uns als Ziffern 0 – 9 zur Verfügung. Bei IP-Adressen lauten die "Ziffern" 0 – 255 (dezimal).

Bei einer Versionskennung muss im Allgemeinen beispielsweise auf v1.0.9 nicht zwangsläufig v1.1.0 folgen (da die einzelnen "Stellen" traditionell* als Hauptversion, Nebenversion und Fehlerbehebungsversion geführt werden). Das heißt, werden erneut lediglich einige Fehler behoben, wird eher v1.0.10 folgen usw. Bei anders aufgebauten Versionskennungen (variierende Stellenanzahl, "beta" etc.) wird es noch schwieriger.

Sollte jedoch, aus welchen Gründen auch immer, jede Stelle auf z. B. 0 – 9 begrenzt sein, so könnten wir natürlich analog zum "üblichen" Dezimalsystem verfahren und als Basis die 10 wählen (oder einfach die Punkte entfernen …), womit das Verfahren wieder funktioniert. Dies dürfte jedoch ein eher seltener und ungewöhnlicher Spezialfall sein, insofern sollte hier der Einfachheit wegen nach wie vor eher stellenweise verglichen werden.


*) Ich persönlich halte daran auch fest. Viele Projekte scheinen diesem Schema jedoch nicht mehr zu folgen. Teilweise gibt es zumindest zur Kommunikation nach Außen gar nur noch eine einzelne Versionsnummer (z. B. v19), was jedoch auf den ersten Blick weniger über den Inhalt der Version aussagt. Es ist sicherlich nicht ganz falsch, dass das den Endanwender auch nicht direkt interessieren muss – praktisch finde ich es trotzdem.

Vorweg sei erwähnt, dass ich mich im weiteren Verlauf des Artikels der Übersicht wegen auf IPv4 beschränken werde. Das vorgestellte Konzept funktioniert prinzipiell jedoch auch bei IPv6 in ähnlicher Form.

Jeder hat bestimmt schon einmal IP-Adressen der Form "127.0.0.1" (lokale Adresse), "192.168.1.1" (private Adresse) oder "217.160.176.125" (öffentliche Adresse) gesehen. Das ist eine für den Menschen bequeme Schreibweise, jedoch nur bedingt zur automatisierten Verarbeitung (z. B. für Vergleiche bei Sortierungen) geeignet.

Eine IPv4-Adresse besteht aus vier Segmenten, die jeweils 8 Bit (≙ 4 * 1 Byte = 32 Bit, bzw. 4 Byte) umfassen. Insofern verwendet eine IPv4-Adresse dieser Schreibweise ("dotted decimal") eine Art Stellenwertsystem wie unser gebräuchliches Dezimalsystem, wobei die einzelnen Stellen jedoch mehrere Ziffern umfassen und daher durch ein Trennzeichen (in diesem Fall ein ".") getrennt werden.

Die Wertigkeit der Stelle einer Zahl unseres Dezimalsystems ergibt sich bekanntermaßen aus dessen Position: Ähnlich verhält es sich nun bei einer IPv4-Adresse, jedoch mit entsprechend anderen Wertigkeiten: In Anbetracht dieser Tatsache können wir einer IPv4-Adresse also einen ein-eindeutigen ganzzahligen Wert zuordnen, indem wir – analog zu unserem Dezimalsystem – die Summe der einzelnen Stellen bilden. Durch diese Darstellungsweise sind nun beispielsweise sehr einfach "größer"- und "kleiner"-Relationen zu ermitteln.

Die zu dieser Thematik passende Eigenschaft Address der IPAddress-Klasse des .NET-Frameworks ist als veraltet gekennzeichnet. Solltet ihr diese Funktionalität dennoch benötigen, so lässt sich dies selbstverständlich auch schnell selbst schreiben – wobei zu berücksichtigen gilt, dass das nur für IPv4-Adressen in dieser Form verwendet werden kann: PHP bietet hier beispielsweise die Funktion ip2long (und deren Gegenstück long2ip) an.

Oftmals sehe ich zur Ermittlung der Anzahl der Ziffern einer Zahl, dass diese explizit in eine Zeichenkette konvertiert und anschließend mit Zeichenketten-Operationen bearbeitet wird. Unter sehr dynamischen Sprachen wie beispielsweise PHP wird einem dies besonders einfach gemacht.

Das funktioniert zwar zweifelsohne und kann je nach Kontext auch der schnellste Weg sein, mathematisch elegant ist das aber nicht und darum möchte ich zumindest der Vollständigkeit wegen gerne aufzeigen, wie sich dieses Problem rein rechnerisch lösen lässt.

Dazu erinnern wir uns zuerst einmal an den Begriff der Größenordnung, welche eine Zahl zu gegebener Basis (im Alltag also meistens die 10, bei Informatikern evtl. auch noch 2, 8 oder 16 ) um eben diesen Faktor erhöht. Anschaulicher lässt sich dies als Potenz vorstellen, bei der der Exponent inkrementiert wird. Da dabei praktisch im jeweiligen Stellenwertsystem auch die Anzahl der Ziffern der jeweiligen Zahl steigt, fällt dem geneigten Leser möglicherweise bereits ein Zusammenhang auf. Zuerst einmal wollen wir die bisherigen Kenntnisse jedoch der Übersicht wegen formal notieren: Es besteht offensichtlich ein Zusammenhang zum Exponenten der Basis des Zahlensystems, wie groß diese Zahl ist – was ja auch völlig klar so sein muss und letztlich keine besondere Erkenntnis ist. Genau diese Rückbesinnung auf Bekanntes bringt uns jedoch zur Lösung des Problems: Wir müssen zu unserer gegebenen Zahl den Exponenten zur Basis des gegebenen Zahlensystems suchen, wodurch unsere Zahl erzeugt wird.

Mit gewissem Entsetzen denken nun vielleicht die ersten Leser spontan an Wurzeln (und nebenbei an ihre letzte Wurzelbehandlung ), aber es ist "noch schlimmer": Da uns Wurzeln die Basis liefern, wir jedoch den Exponenten benötigen und das Kommutativgesetz bei Potenzen im Allgemeinen nicht gilt (d. h. a^b ≠ b^a), benötigen wir die zweite Umkehroperation – den Logarithmus.

Dieser löst uns die Gleichung 10x = Zahl nach x auf und damit haben wir bereits beinahe die Lösung unserer eigentlichen Fragestellung. Da der Exponent auch Dezimalstellen enthalten kann, die Anzahl der Ziffern jedoch in jedem Fall eine natürliche Zahl sein muss, runden wir das Ergebnis erst einmal pauschal ab. Da die Zählung des Exponenten nun auch noch bei 0 beginnt (was uns als Softwareentwickler aber nur mäßig schockieren dürfte ), korrigieren wir diesen Versatz durch Addition von 1 und erhalten folgende Lösung:

Anzahl der Ziffern einer Zahl (im Dezimalsystem) = ⌊log₁₀ Zahl⌋ + 1

Natürlich lässt sich dies auch in Programmen sehr einfach verwenden, daher wollen wir eine Erweiterungsmethode für ganze Zahlen in C# schreiben, die uns die Anzahl der Ziffern liefert: Wir berücksichtigen dabei die 0 separat und beugen außerdem Problemen mit negativen Zahlen durch Verwendung der Betragsfunktion vor. Die Anwendung gestaltet sich nun denkbar einfach: Natürlich wäre auch die Implementierung in Form einer Schleife, welche die Zahl fortlaufend durch die Basis (10) teilt, denkbar, um die Anzahl der Ziffern zu ermitteln. Aber das sei dem geneigten Leser zur Übung überlassen.

C# ist und bleibt zwar eine grundsätzlich statisch typisierte Programmiersprache, erlaubt jedoch auch die implizite Typisierung mit Hilfe des var-Schlüsselwortes: Der konkrete Typ wird dabei implizit durch den Wert auf der rechten Seite bestimmt. Dies kann den Quelltext besonders bei komplexen Strukturen (z. B. im Hinblick auf generische Programmierung) etwas kompakter gestalten, je nach Gewohnheit aber auch etwas schwerer zu verstehen sein. Es bleibt wie so oft dem Entwickler (bzw. den Richtlinien des Teams) überlassen, wie damit umzugehen ist.

Wichtig zu verstehen ist in jedem Fall, dass var in diesem Fall nur ein syntaktisches Hilfsmittel ist und keine dynamische Typisierung eingeführt wird (dazu in einem späteren Artikel mehr). Das bedeutet insbesondere, dass unserem "age" später nicht etwa eine Zeichenkette zugewiesen werden kann.

Zwingend notwendig ist diese Vorgehensweise jedoch bei anonymen Typen, da der Typ keinen (bzw. lediglich einen internen, dem Compiler bekannten) Typenbezeichner besitzt: Auch im Rahmen von LINQ-Abfrageausdrücken kann dieses Vorgehen beispielsweise bei der Projektion von Daten aus einer Liste mittels Select(…) notwendig sein (aus ähnlichen Gründen wie im Beispiel zuvor).