Das Rad neu erfinden? Nein!

Heute Früh, zwischen 2 und 3 Uhr bin ich plötzlich aufgewacht und konnte nicht mehr einschlafen. Ohne Witz!
Mir gingen die ganze Zeit Ideen für weitere Features meiner begonnenen "Atomix" Anwendung durch den Kopf. Sind die Ideen mit dem MPT Konzept umsetzbar? Die Gedankenexperimente gingen los und ich kam immer zu dem selben Ergebnis: Natürlich ist das umsetzbar! Unter Zuhilfenahme der MPT ist das sogar sehr einfach, da man sich ja keine Gedanken über die Objektabhängigkeiten machen muss. Man geht ja bei der Implementation einfach davon aus, dass man die benötigten Daten einfach von irgendwoher bekommt. Und dann nutzt man einfach diese Daten für sein gewünschtes Feature.
Früher habe ich mir eher den Kopf darüber zerbrochen, wie ich die Objekte am Besten miteinander verkopple, um zu dem gewünschten Feature zu kommen:

Injiziere ich Objekt "A" in Objekt "B", oder doch besser Objekt "B" in Objekt "A"? Und was ist, wenn ich in Objekt "A" nur einen Teil der Daten von Objekt "B" benötige? Vielleicht benötige ich nur einen bestimmten String von Objekt "B"? Weshalb also Objekt "A" vom kompletten Objekt "B" abhängig machen? Ich kann es aber auch nicht anders machen, weil ich z.B. den String irgendwann dynamisch zur Laufzeit benötige. Also muss ich es doch so machen.
Und wenn ich in Objekt "B" noch mit Objekt "A" hantieren will? [usw. usf.]

Diese Überlegungen entfallen bei der MPT völlig, da hier im Grunde alle Objekte auf der selben Ebene stehen. Und kein Objekt interessiert sich dafür, wo es seine Daten herbekommt oder wo seine eigenen Daten hingehen. Man benötigt eine bestimmte Datenstruktur für Irgendwas Bestimmtes? Passende Schnittstelle dafür implementieren und seine Idee fortsetzen.

Dadurch sind massenhaft Features durch meinen Kopf gegangen. Das hat kaum ein Ende genommen. Echt schlimm, wenn man dabei durch nix gebremst wird ... höchstens seine eigene Fantasie. Und ehe ich mich versah, ging schon wieder die Sonne auf. *g*

Aber dennoch kam ich an einen Punkt, der mich heute den ganzen Tag stark beschäftigt hat:
"Atomix" wird auch Quellcode parsen müssen! Soll ich da anfangen, einen eigenen Parser zu entwickeln oder eine existierende Lösung suchen?

Ich dachte tatsächlich erst daran, einen eigenen Parser zu entwickeln. Schnell mal nach der offiziellen C# Spezifikation gegoogelt und den Standard ECMA-334 gefunden. "Rein geguckt und zam gezuckt!", wie es so schön heißt. ^_^
Dass C# komplex ist, ist klar. Aber dieses Dokument hat es schon in sich. Eben eine richtige Spezifikation.

Ich hielt dennoch an dem Gedanke fest, einen eigenen Parser zu entwickeln. Aber mir fehlte ein bisschen der konkrete Ansatz, wie man sowas programmiert. Also nochmal gegoogelt und ich fand das: "Writing a parser: overview".

Nun war die dort erfundene Beispielsprache ja recht einfach. Einfacher, als etwa C#. Und dennoch ist der Parser für jene einfache Sprache so komplex. Wie würde der erst bei C# aussehen? So einen Parser hat man jedenfalls nicht mal so eben nebenbei programmiert.

Nun will ich ja im Grunde nur ein RAD-Tool entwickeln, welches mir ein bisschen Arbeit abnehmen soll. Und der dafür benötigte Parser ist da eher ein notwendiges Übel. Der soll bei der Entwicklung nicht mehr Aufmerksamkeit bekommen, als meine eigentliche Anwendung.
So kommen wir wieder auf die Überschrift dieses Beitrages zurück. Ist es notwendig, das Rad neu zu erfinden? Also in dem Falle, sicher nicht! Ich kenne mindestens ein Projekt, welches einen Parser verwendet, wie ich ihn benötige: "SharpDevelop".
Ich lud mir den Sourcecode von SharpDevelop runter und stöberte darin nach etwas, was "Parser" hieß. Ich hatte auch etwas gefunden, aber es war nicht direkt das, was ich erwartet hatte.
Also googelte ich nochmal, weil ich wissen wollte, wie man den Parser von SharpDevelop für eigene Projekte nutzen kann. Tatsächlich fand ich auch etwas: "NRefactory".
Das sieht sehr vielversprechend aus und scheint einfach verwendbar zu sein. (Und wenn man einmal weiß, wonach man suchen muss, findet man es auch gleich im Quellcode von SharpDevelop wieder. *g*)
Ich fand auch noch eine Auflistung von verschiedenen Parsern bei Google: "Parser for C#".

Hmmm, dort fiel mir auch die "Common Compiler Infrastructure: Metadata API" ins Auge. Das werde ich mir vielleicht auch mal näher ansehen.
Aber theoretisch dürfte für meine Zwecke die normale "System.Reflection" ausreichen. Mal gucken.

Tja, nun hätte sich im Grunde die Sache mit dem Parser erledigt und ich kann mich wieder voll und ganz auf meine eigentliche Anwendung konzentrieren. :-)