Re: [DSA Manager] Modifikatoren-Ausdrücke

[Oliver S. <wh...@us...>]

Hi Leute!

Matthias schrieb:
> (Wollte damit nur sagen, dass man unsere Variante auch "schneller" 
> machen KANN.)

Wie schon gesagt - ich habe bei keinem der beiden Vorschläge
echte Sorgen, daß es zu langsam wird.

> Bei Oliver (in etwa zumindest):
> <Modifikator ausdruck="VNT_BLA.kosten *= 2"/>

Ja, so würde ich das vorschlagen. Ich finde, dies
entspricht auf sehr natürliche Weise den Regeln,
wie sie auch im Freitext formuliert werden.

> Wenn man aber davon ausgeht, dass es aber meist so aussehen wird:
> <Modifikator ausdruck="EIG_MU+=2">
> dann ist
> <Modifikator auf="EIG_MU" ausdruck="2">
> auch nicht gerade unübersichtlich, wenn man attribut="effektiv" und 
> operand="+" als DEFAULT annimmt.

Ok, bei rein additiven Modis ist's nicht viel
länger. Aber bei komplexen Modis schon, oder sie
sind evtl. gar nicht  darstellbar, ohne noch mehr
Erweiterungen. Das mit dem Default-Operator ist
eine Ersparnis, aber es ist insgesamt doch umständlicher.
Erst recht, wenn noch Schachtelungen dazukommen.

> Das die beiden Sachen semantisch gleich sind, streitet wohl niemand an, 
> dass Olivers Variant oftmals weniger "Overhead" erzeugt, auch.
> 
> ICH für meinen Teil bin aber der Ansicht, dass wir aus XML Informationen 
> besser extrahieren können, wenn wir die 'auf'-Tags verwenden, etc.

In der Tat sind meinem Modell mehr Informationen für den
reinen XML-Parser nicht zugänglich. Ich sehe das aber nicht
als Problem, aus folgendem Grunde: Diese Informationen
werden nur bei der Auswertung der Ausdrücke gebraucht.
Und dort steht ja auch ein entsprechender Parser zur
Verfügung. Ich sehe keinen Vorteil darin, einen Teil
der Ausdrücke (z.B. die Schachtelung) in XML auszulagern,
da man mit diesem Teil allein nichts anfangen kann.
Wenn nicht der gesamte Ausdruck, einschließlich
jeder Operation, komplett in XML codiert wird, ist
das Konstrukt ohne den Ausdrucksparser IMHO eh nicht
nutzbar.

Mein Modell kommt zudem insgesamt mit weniger Konstrukten
aus, um die nötige Leistungsfähigkeit zu erreichen - es ist
schlanker.

> Das kann z.B. für "Debuggen" der Ausdrücke nützlich werden, falls sich 
> mal irgendwo ein Fehler einschleicht.

Ich denke, mein Modell ist hervorragend zu debuggen, sowohl
Implementierung, wie auch die eigentlichen Scripte, aus folgenden
Gründen:

- Die Schnittstelle zwischen Scriptsparser/-auswerter
  und der XML-Engine & Co. kann sehr schmal ausfallen.
  Das Scripting braucht kein XML, der Rest braucht sich
  und Bedingungen, Operationen, etc. nicht zu kümmern.
  Die Schnittstelle kann z.B. lediglich in einem Environment-
  Object bestehen, daß als Charakterinterface das Lesen und
  Setzen von Werten ermöglicht.
  Es kann z.B. auch leicht eine Debugging-Enviroment erstellt
  werden, das ein gründliches Testen von Scripts ermöglicht.
  Die Scripte selbst sind zudem in sich geschlossene Objekte,
  und daher unkompliziert zu handhaben.

- Meine Scripts werden linear ausgewertet, nicht rekursiv
  wie eure Ausdrücke. Wenn man dann einen Script-Bug sucht,
  ist linear erheblich leichter durchschaubar als rekursiv.
  Kann man z.B. leicht loggen, und sehen, wo der Wurm ist.

- Die klare Trennung von Charakter/Werten/XML und
  Scripts/Operationen ermöglicht eine streng modulare
  Implementierung, die viel leichter zu testen ist
  als eine gemischte Implementierung.

- Da die Ausdrücke sehr "natürlich" sind, halte ich meinen
  Ansatz von vornherein für weniger Fehler anfällig.

> Außerdem denke ich noch, dass wir es im XMLReader einfacher haben 
> werden, wenn wir die XML-nähre Variante verwenden.

Da man auch eure Ausdrücke parsen muß, braucht man
eh einen Parser zusätzlich zum XML Reader. Ob der
dann ein bischen mehr oder weniger tut, macht doch
keinen Unterschied. Die kompletten Script-Syntaxbäume
wären in jedem Fall voll zugänglich. Es ist nicht so,
daß man an irgend was schwer rankommt.

> So, bin jetzt schon gespannt, was für Argumente von Oliver ausgekramt 
> werden... ;-)

Nun, ich hab versucht, meine Argumente hier nochmal
zusammenzufassen. Ergänzend ist noch anzufügen, daß
Scripting mit unvorhergesehen Aufgaben deutlich besser
klarkommt, als die XML+Ausdrücke Variante, wie wir am
Beispiel "multiplikative Modis" erlebt haben. Wie
wichtig das ist, wird jeder unterschiedlich beurteilen.
Ich persönlich hab im Design immer gern ein paar Reserven.

> Und nachdem dann alles vorgetragen wurde, sollten wir einfach 
> demokratisch abstimmen. Sonst nimmt das kein Ende.

Wohl war ...

cu
Oliver