Minecraftforge: Rezept-/Konditionsfabriken können nicht über den Code registriert werden

Erstellt am 2. Aug. 2017  ·  3Kommentare  ·  Quelle: MinecraftForge/MinecraftForge

Die einzige Möglichkeit, Rezept- und Bedingungsfabriken zu registrieren, besteht derzeit darin, ein FQCN in eine zufällige Json-Datei einzufügen, die scheinbar nachträglich eingefügt wurde. Codebezogene Identifikatoren haben keinen Platz in Datendateien, insbesondere nicht vollständig qualifizierte Klassennamen. Das bedeutet nicht nur, dass Plugins, die Code statisch auf ungenutzte Teile analysieren, es schwerer haben und unnötig komplex sein müssen, um überhaupt zu funktionieren, sondern es macht auch keinen Sinn, dass eine Datendatei der Engine sagt, welche Factory sie laden soll. Fabriken müssen nicht basierend auf benutzerdefinierten Bedingungen geladen werden, und sie müssen nicht mehr als einmal geladen werden.

Daher sollte die Rezept- und Bedingungs-Factory-Registrierung in ein Ereignis beim Start oder ähnliches verschoben werden, um Code sauber von Daten zu trennen.

Hilfreichster Kommentar

Es ist eine Wahl des Codestils und eine funktionale Wahl, die KEINE nachträgliche Überlegung war.
Ich beschloss, diesen Weg zu gehen, damit Dinge leicht indiziert werden können, ohne binäre Klassendateien von Ressourcenpaketherstellern und anderen rezeptbezogenen Tools durchsuchen zu müssen. Es ist wichtig, einen zentralen Ort zu haben, um zu sehen, was ihnen zur Verfügung steht. Es wäre schön, wenn Sie keine vollqualifizierten Namen verwenden müssten oder Sie gezwungen wären, eine Dokumentation darüber zu verwenden, was jede Fabrik tat/verwendet wurde. Aber diese Art von Sachen kann nicht codetechnisch erzwungen werden, also sind wir hier.

Es soll auch Modder zwingen, über ihre Rezepte nachzudenken und klar zu definieren, wie sie strukturiert sind, und sie hoffentlich generisch und wiederverwendbar zu machen. Sowie alle bedingten Definitionen von Fabriken zu entfernen, weil Sie sich an diesem Tag fühlen. Da es wichtig ist, ein stabiles Ziel auf der Seite der Pack-Entwickler zu haben. Darüber hinaus denke ich ehrlich daran, die Fabriken vielleicht auf Javascript zu erweitern, anstatt nur auf Json. Damit die eigentliche Funktionalität in der Datei kontrolliert wird und potenziell selbstdokumentierender wäre, da die Leute überprüfen könnten, was tatsächlich vor sich geht. Aber das verschiebt die Dinge in einen ganz anderen Bereich, den ich an dieser Stelle nicht tun möchte.

Auch hier kommt es am Ende des Tages auf den Codestil an. Ja, es ist ein bisschen nervig, vollständige Klassennamen in eine JSON-Datei einfügen zu müssen. Aber in Plugin-Systemen ist es ziemlich üblich, Ihre Einstiegspunkte irgendwo außerhalb des Codes zu definieren. Ich habe auch mit der Idee gespielt, einfach eine einzelne Klasse anzugeben oder Sie zu zwingen, eine einzelne Klasse mit einem bestimmten Namen zu verwenden, die es ermöglichen würde, mehrere Fabriken in einer .java-Datei zu definieren. Aber ich habe mich noch nicht hingesetzt und diese Ideen durchgearbeitet.

Ein Teil des Punktes ist, dass ich dabei an mehr als nur Leute denken muss, die Mods schreiben. Ich muss an Pack-Hersteller, Endbenutzer und Tools von Drittanbietern denken. Denn ja, diese Art von Menschen sind ein großer Teil der Rezeptgemeinschaft / des Publikums. Sie sollten sich um sie kümmern. Es ist wichtig, einen zentralen Ort mit diesen Informationen zu haben, die nicht aus binären Klassen herausgeparst/dekompiliert werden müssen. Werfen Sie ein paar Kommentare in diese json-Dateien ein, um zu dokumentieren, wie die Fabriken verwendet werden, und Sie haben eine nette Ressource, auf die Nicht-Programmierer verweisen können!

"Man könnte sagen, es entspricht der Registrierung von Blöcken und Elementen über JSON." Wenn Sie in den letzten 2 Jahren der Entwicklung nicht aufgepasst haben, versucht Minecraft genau dorthin zu gehen. Komm damit klar.

"Man könnte sich fragen, warum die eingebauten Fabriken nicht über JSON hinzugefügt werden." Dies ist ehrlich gesagt, weil ich zu der Zeit, als ich das gesamte Ladesystem entwickelte, das Zeug etwa 5 Mal neu schreiben musste und ich zu anderen Dingen übergehen wollte. Eine davon war das Konzept, dieses Zeug im Code zu registrieren. Deshalb gibt es die Registerfunktionen noch. Aber ich habe das aufgegeben, um den Packherstellern mehr Macht zu geben. Ich sollte zurückgehen und das in eine _factories.json aufräumen, aber das ist später.

TLDR: Ja, ich weiß, dass die Angabe von vollständigen Klassennamen für die Leute ein wenig schmutzig / nervig ist. Ich habe gute Gründe, diesen Weg zu gehen. Und ich bin offen für Möglichkeiten, es sauberer zu machen, ohne die Möglichkeit für Nicht-Programmierer zu opfern, diese Daten zu kennen / zu handhaben / zu verwenden. Aber jetzt haben wir das hier.

Alle 3 Kommentare

Absolut einverstanden. Ich sehe keinen Vorteil darin, diese von vornherein über JSON zu registrieren. Was Sie verlieren, ist die statische Überprüfbarkeit und die Möglichkeit, diese Objekte nach Belieben zu konstruieren. Was Forge gewonnen hat, ist Komplexität. Man könnte sagen, es entspricht der Registrierung von Blöcken und Elementen über JSON.

Sie könnten sich fragen, warum die integrierten Factorys nicht über JSON hinzugefügt werden.

Es ist eine Wahl des Codestils und eine funktionale Wahl, die KEINE nachträgliche Überlegung war.
Ich beschloss, diesen Weg zu gehen, damit Dinge leicht indiziert werden können, ohne binäre Klassendateien von Ressourcenpaketherstellern und anderen rezeptbezogenen Tools durchsuchen zu müssen. Es ist wichtig, einen zentralen Ort zu haben, um zu sehen, was ihnen zur Verfügung steht. Es wäre schön, wenn Sie keine vollqualifizierten Namen verwenden müssten oder Sie gezwungen wären, eine Dokumentation darüber zu verwenden, was jede Fabrik tat/verwendet wurde. Aber diese Art von Sachen kann nicht codetechnisch erzwungen werden, also sind wir hier.

Es soll auch Modder zwingen, über ihre Rezepte nachzudenken und klar zu definieren, wie sie strukturiert sind, und sie hoffentlich generisch und wiederverwendbar zu machen. Sowie alle bedingten Definitionen von Fabriken zu entfernen, weil Sie sich an diesem Tag fühlen. Da es wichtig ist, ein stabiles Ziel auf der Seite der Pack-Entwickler zu haben. Darüber hinaus denke ich ehrlich daran, die Fabriken vielleicht auf Javascript zu erweitern, anstatt nur auf Json. Damit die eigentliche Funktionalität in der Datei kontrolliert wird und potenziell selbstdokumentierender wäre, da die Leute überprüfen könnten, was tatsächlich vor sich geht. Aber das verschiebt die Dinge in einen ganz anderen Bereich, den ich an dieser Stelle nicht tun möchte.

Auch hier kommt es am Ende des Tages auf den Codestil an. Ja, es ist ein bisschen nervig, vollständige Klassennamen in eine JSON-Datei einfügen zu müssen. Aber in Plugin-Systemen ist es ziemlich üblich, Ihre Einstiegspunkte irgendwo außerhalb des Codes zu definieren. Ich habe auch mit der Idee gespielt, einfach eine einzelne Klasse anzugeben oder Sie zu zwingen, eine einzelne Klasse mit einem bestimmten Namen zu verwenden, die es ermöglichen würde, mehrere Fabriken in einer .java-Datei zu definieren. Aber ich habe mich noch nicht hingesetzt und diese Ideen durchgearbeitet.

Ein Teil des Punktes ist, dass ich dabei an mehr als nur Leute denken muss, die Mods schreiben. Ich muss an Pack-Hersteller, Endbenutzer und Tools von Drittanbietern denken. Denn ja, diese Art von Menschen sind ein großer Teil der Rezeptgemeinschaft / des Publikums. Sie sollten sich um sie kümmern. Es ist wichtig, einen zentralen Ort mit diesen Informationen zu haben, die nicht aus binären Klassen herausgeparst/dekompiliert werden müssen. Werfen Sie ein paar Kommentare in diese json-Dateien ein, um zu dokumentieren, wie die Fabriken verwendet werden, und Sie haben eine nette Ressource, auf die Nicht-Programmierer verweisen können!

"Man könnte sagen, es entspricht der Registrierung von Blöcken und Elementen über JSON." Wenn Sie in den letzten 2 Jahren der Entwicklung nicht aufgepasst haben, versucht Minecraft genau dorthin zu gehen. Komm damit klar.

"Man könnte sich fragen, warum die eingebauten Fabriken nicht über JSON hinzugefügt werden." Dies ist ehrlich gesagt, weil ich zu der Zeit, als ich das gesamte Ladesystem entwickelte, das Zeug etwa 5 Mal neu schreiben musste und ich zu anderen Dingen übergehen wollte. Eine davon war das Konzept, dieses Zeug im Code zu registrieren. Deshalb gibt es die Registerfunktionen noch. Aber ich habe das aufgegeben, um den Packherstellern mehr Macht zu geben. Ich sollte zurückgehen und das in eine _factories.json aufräumen, aber das ist später.

TLDR: Ja, ich weiß, dass die Angabe von vollständigen Klassennamen für die Leute ein wenig schmutzig / nervig ist. Ich habe gute Gründe, diesen Weg zu gehen. Und ich bin offen für Möglichkeiten, es sauberer zu machen, ohne die Möglichkeit für Nicht-Programmierer zu opfern, diese Daten zu kennen / zu handhaben / zu verwenden. Aber jetzt haben wir das hier.

Auch wenn das Ergebnis meiner Meinung nach nicht zufriedenstellend ist, ist es schön, einige Argumente dafür zu bekommen, warum das System so ist, wie es ist. Besser als "JSONs verwenden".

Weiter so

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen