Game/Dungeon: Modellierung der Konfiguration refactoren

[cagix]

Die Klassen unter core.configuration und contrib.configuration sind etwas verwirrend in ihrer Vielfalt, und wirklich gut dokumentiert ist das auch nicht.

• core.configuration.KeyboardConfig definiert eine Reihe von Konstanten vom Typ ConfigKey<Integer> => Zuordnung der Tastencodes in libGDX. contrib.configuration.KeyboardConfig dito, allerdings werden hier weitere/andere Codes definiert. Dabei wird jeweils ein String-Array mit zwei Plätzen genutzt plus ein Element vom Typ ConfigIntValue.
  • Frage 1: Warum ein String-Array mit zwei Plätzen und nicht zwei Strings?! Das würde allen die Nutzung sehr erleichtern!
  • Frage 2: Warum wird der Integer für den Tastencode nochmal als ConfigIntValue verpackt?
  • Frage 3: Warum sind das kein Enums, sondern zwei Klassen mit lauter public Konstanten? Ich hätte die Klassen verstanden, wenn es eine Ableitungsbeziehung gäbe, d.h. wenn contrib.configuration.KeyboardConfig von core.configuration.KeyboardConfig erbt und damit die Konstanten ergänzt. Passiert aber irgendwie nicht?
  • Die Klasse ConfigIntValue bzw. ihre Elternklasse ConfigValue<Integer> hat einen Setter void value(final T value). Wozu?! Der wird ausschliesslich in ConfigKey<Type> verwendet im Setter, der nirgendwo verwendet wird.
  • Die in core.configuration.KeyboardConfig verwendete Modellierung ist vom Typ ConfigKey<T>.
    • Frage 1: Warum hat auch diese Klasse einen Setter void value(T value)?! Der wird lt. IntelliJ nirgendwo benutzt?!
    • Frage 2: Warum ist das kein Record?!
    • Frage 3: Warum ist das generisch? Wir verwenden lediglich ConfigKey<Integer>, wenn ich das richtig sehe?
• Wie hängt das alles mit der DSL zusammen? Was geht kaputt, wenn wir hier anfassen?

Hier muss mal aufgeräumt werden. Brauchen wir diese hohe Komplexität wirklich für irgendwas? Ist das irgendwo dokumentiert?

[cagix]

@AMatutat Du kennst die Entstehungsgeschichte des Dungeons gut. Kannst Du hier bitte mal was dazu sagen? Vielleicht verstehe ich auch einfach nur irgendwas nicht, und die Modellierung muss so.

[AMatutat]

Ich meine mich zu erinnern, dass @fwatermann diese ganzen ConfigIntValue etc. Werte/Klassen gebraucht hat, um die Konfiguration am Ende auch gescheit serialisieren (und nachher auch wieder einladen) zu können. Das spuckt dir am Ende eine json aus.

DSL Connection dürfte das nicht haben.

Zu den anderen Fragen kann ich keine qualifizierte Aussage machen.

[cagix]

not amused