Erstmal vorweg, danke für das detaillierte Feedback und teils interessanten neuen Informatioen! 
Da viele deiner Punkte sich thematisch teils überschneiden, hier erstmal der Grund, wie, warum, weshalb:
Mir ging es darum, so viele Fehlerquellen wie möglich bei der Eingabe vom Nutzer zu vermeiden. Es kann schnell passieren, dass bei der Eingabe etwas schief geht, besonders bei Anfängern und die aufgeben oder andere mit Fragen zu bombardieren, die vermeidbar gewesen sind. Zudem gibt es keine einfache und schnelle Möglichkeit in Lotus zu prüfen, ob alle Eingaben korrekt erfasst worden sind. Sodass einige Nutzer dann eher aufgeben, als die eigenen Ideen zu verwirklichen.
Alles einheitlich in der Dokumentation darzustellen (Case-Sensitive, ein einheitliches Zuweisungsoperator, einheitliche Farbangaben) war sowieso vorgesehen und diente hier nur zum Zeigen, was für den Parser nicht in die Knie zwingt.
Flexibilität bei der Eingabe war und ist hier wohl das Motto.
Die Idee davon, TOML vollständig zu verwenden und nicht "ein paar Konzepte zu übernehmen", ist es später im neuen Script System bereits vorhandene Parser verwenden zu können. Wenn man doch vom Standard einer Formatdefinition abweicht, kann man auch komplett seinen eigenen Kram machen, weil so der große Vorteil auf bestehende Lösungen zurückgreifen zu können verloren ist.
Hätte ja jemand auch vorher vermerken können, dass das im neuen Script System geht^^
Ne aber am Ende hat auch reines TOML, wie auch INI-Dateien, Vor- und auch Nachteile und wie bereits erwähnt war es mir wichtig Fehlerquellen soweit wie möglich abzustellen und es dem Nutzer so einfach wie möglich zu machen.
Da das Script zudem über OpenLotus veröffentlicht wird, kann jeder es als Schnittstelle verwenden und standardisiert Daten abrufen.
Apropos neues Script-System: Auch dies sollte kein Problem sein. Der Parser kann einfach die Eingaben "übersetzen" bzw. die fehlerhaften Eingaben korrigieren und es dann über die TOML-Bibliothek endgültig parsen.
Zitat von Pandemist
Es wäre sehr hilfreich, wenn ihr euch auf einen Case einigen könntet. In einer Definition wird sowohl camelCase, snake_case und kebab-case verwendet. Sowas ist einfach schlechter Stil.
UpperCamelCase ist als Vorgabe vorgesehen, aber wie gesagt, fliegt uns der Parser nicht um die Ohren, wenn irgendjemand unabsichtlich oder absichtlich snake_case o.Ä. verwendet.
Zitat von Pandemist
Generell gilt hier dasselbe wie oben. TOML erlaubt zwar verschiedene Keys, aber auch hier die Frage, warum muss es mehrere geben. In einem guten Standard gibt es für einen Parameter auch nur genau einen Key. Sobald man Alternativen anbietet, müsste man auch Regeln anbieten, was passiert, sollten mehrere Keywords genutzt werden, die denselben Parameter beschreiben. Spätestens ab da wird es nur unnötig kompliziert.
Einfache Regel: Ein Parameter = ein Keyword.
Bei dem Beispiel von deinem verwendeten Zitat soll standardmäßig immer "col" verwendet werden, weil weniger Zeichen. Falls aus Gewohnheit jetzt jemand "color" oder "colour" schreibt, wird es einfach nur intern mit "col" ersetzt und fertig.
Ich wüsste jetzt nicht auswendig, ob es noch andere Keys gibt, die den selben Parameter beschreiben, aber das dürfte nicht der Fall sein. Und auch wenn, würden die sich nur gegenseitig überschreiben (und da intern für alle Zusatzstrings immer die gleiche Funktion aufgerufen wird, kommt es zwangsläufig dazu, dass gleiche Keys sich gegenseitig überschreiben).
Zitat von Pandemist
Die Darstellung von Farben als Dezimalzahl führt dann zu Problemen, wenn man auch eine Darstellung im Binär- oder Hexformat zulässt.
Beispiel:
Wenn man für eine Farbe den Wert 255255255 (als Dezimalzahl) oder den Wert 0xFFFFFF (als Hex) angibt, sollen diese dieselbe Farbe beschreiben. Ein Parser für TOML wandelt, diese beiden Angaben wie folgt um:
255255255 ist eine Dezimalzahl und wird als Integer 255255255 im Programm dargestellt.
0xFFFFFF ist eine Hexadezimalzahl und wird umgewandelt zum Integer 16777215.
Wir sehen also direkt die Diskrepanz. Das ursprüngliche Format kann somit nach dem Parsen nicht mehr nachvollzogen werden.
Ich würde also vorschlagen, die Darstellung der Farbe als Dezimalzahl nicht mit anzubieten. (Zumal die 9 stellige Zahl eh nicht sehr übersichtlich aussieht)
Alles anzeigen
Stimmt, mit der neuen Information zum neuen Script-System, macht es schon Sinn, das ein wenig darauf vorzubereiten.
Wie wäre es, wenn die Farben wie folgt angegeben werden?
- ColorXY = {255, 255, 255, 255} //R, G, B, A
- //oder
- ColorXY = {Red = 0xFF, Green = 0xFF, Blue = 0xFF, Alpha = 0xFF} //Hier wäre der Vorteil, dass nicht alle Kanäle angegeben werden müssen, da die dann als 0 oder 255 interpretiert werden. Ob 0 oder 255 müsste dann natürlich auch festgelegt werden
- //Binär, Dezimal oder Hexadezimal würden weiterhin alle unterstützt werden können.
Zitat von Pandemist
Ich würde abschließen noch dazu aufrufen (Beispiel unabhängig) sich für jedes erlaubte Keyword zu überlegen, ob es auch das beschreibt, was der Name aussagt.
Nennen wir das Problem "Wachstumsschwierigkeiten" ;D
Da die Bezeichner teils für meine Anzeige und dann auch noch teils mit etwas anderen Funktionen vorgesehen war und sich nach und nach das Thema hier entwickelt hat, haben sich die Keywords nicht mitentwickelt - wird natürlich, am Besten, gleich angepasst.
------
Im neuen Script System würde ich das Script so umsetzen, wie oben bereits angeschnitten, dass dem jeweiligen TOML-Parser eine Funktion vorgestellt wird, welche die fehlerhaften Eingaben korrigiert, es dann mittels TOML-Parser verarbeitet und dann in die gewohnte Datenstruktur bringt. Für den PISSP-Ersteller und Anzeigenersteller würde sich nichts ändern, da die Schnittstellen zum und vom Script gleich bleiben. Möglicherweise werden dann mehr Vorteile von TOML unterstützt, was aber auch dann für alle Parteien kein Problem darstellen sollte.
Dies ist der Kommentarthread zum Addon: [
This is the commentary thread concerning addon: [Name & Link to presentation thread]
