Spaß ist in der Tat der treibende Faktor. Für meine gesamte Tätigkeit in der Eisenbahnsimulations- und Kartenwelt.Christopher Spies hat geschrieben:Roland bastelt sich seine eigene Skriptsprache und zugehörigen Interpreter aus Spaß.
Um das API statisch zu nutzen, muss die Anwendung zur Compilezeit entsprechend zugeschnitten sein. Genau das wäre für meine Zwecke unpraktischReflection ist mir bekannt. Mir ist jedoch nicht klar, was im Rahmen des Stellwerk-Projekts der Vorteil davon ist. Die API steht doch fest, oder irre ich mich da?
Für mich geht es schneller, in einem kurzen, kompakten Skript-Quelltext zu ändern, der für die angestrebten Zweck keinen Overhead mit sich führt, als im wesentlich komplexeren C#-Quelltext die verteilten Stellen heraussuchen zu müssen.Aber so musst Du den Source-Code der Testskripte ändern, wie spart das Arbeit?
Es gibt ja so eine teils juristische Definition zur Unterscheidung von Daten und Programm. Ein Programm soll demnach gegenüber einer reinen Datendefinition logische Abläufe, einschließlich Verzweigung, enthalten. Und ein "if" werde ich brauchen.Die Skripte sind also nur Konfigurationsdateien für allgemein gehaltene Testfälle. Früher hätte man so etwas vielleicht als Textdatei im INI-Format realisiert.
Getestet wird Software sinnvollerweise auch von Nicht-Entwicklern. Ein Merkmal von QS.Die Skriptsprache muss so simpel sein, dass Nichtprogrammierer als Testsklaven herhalten können.
So wie geliefert, sehe ich für die Skriptsprache über meine eigene Entwicklung hinaus die denkbare Anwendung für den Stellwerks-Konfigurierenden auf der Server-Seite, also in der Emulation, auch ohne Zusi.
Zudem wird die Assembly, auf die der Interpreter wirkt, frei wählbar sein. Man wird also seine eigenen Adapterklassen schreiben können. (Der Interpreter selbst arbeitet nach dem Command-Pattern.) Mit dieser Eigenschaft könnte das Teil auch denjenigen Softwareentwicklern helfen, die selber einen neuen Client entwickeln wollen.
Aber all das ist derzeit noch gar nicht meine Intention. Die Idee ist schlicht aus der Skizzierung von sinnvollen Testfällen geboren.
Die BNF-Analyse-Klassen werden entweder noch heute oder sonst morgen wohl in einer ersten Version laufen. Der Klassengenerator des Interpreters kann das Beispiel-Statement bereits generieren. Allerdings gefiel mir mein Ansatz nicht, und deswegen habe ich auf BNF erweitert. Das ist also insgesamt vom Arbeitsaufwand keine Frage von Wochen, sondern Tagen (die zeitliche Verteilung dieses Aufwandes steht immer auf einem anderen Blatt).
Ich versteh schon, es wird Zeit, sich endlich mit Handfesterem zu beschäftigen. Es ist wohl eine Krux heutiger Software, dass das Sichtbare auch im übertragenden Sinne nur die Oberfläche darstellt. Das ist allerdings eine Erfahrung, die mich mein schon mein ganzes Berufsleben begleitet. Auch da gibt es so eine 80/20-Regel (je nach Branche und Projektart): 80% der Software sieht man nicht. (Ich denke, das Verhältnis kann noch weitaus drastischer ausfallen.)Michael_Poschmann hat geschrieben:komplette stellwerksbezogene Fachliteratur innerhalb der Stadtgrenzen