Yarn: 'Entity'-Suffixe löschen

Dies lässt nur Entity für reguläre Entitäten fallen und nicht für BlockEntities, ja?

Ja.

Schwamm verwendet auch keine Entity Suffixe.

+1 aber kann dieses Argument nicht auch für Dinge wie Blöcke verwendet werden? Es kollidiert fast nie. Die Idee mit Blöcken gefällt mir. Truhe, aber wenn Sie etwas machen, das nicht streng blockbezogen ist, wird es seltsam.

Ich stimme der Konsistenz wegen nicht zu

Die Sache mit dem Block Suffix, IMO, ist, dass es nicht nur einen Block, sondern den Block bezeichnet. Nehmen wir zum Beispiel Gras, es gibt immer nur eine Instanz von GrassBlock zu einem bestimmten Zeitpunkt, also kann man mit Sicherheit sagen "Dies ist der Grasblock". Entitäten funktionieren nicht wirklich so, weil es für jede Entität auf der Welt eine Instanz der Entität gibt. Als weiteres Beispiel können Sie bei Zombies nicht sagen "Das ist der Zombie", weil es mehrere Zombies gibt, nicht nur einen. Du würdest sagen "Das ist ein Zombie".

Andererseits ist das Konsistenzargument ein gutes Argument - es ist ein bisschen inkonsistent, wenn wir einige Dinge mit ihrem Typ anhängen und die anderen ohne Suffixe belassen.

hmm, wie wäre es mit fallendem Block?

@Sorixelle macht einen wirklich guten Punkt. Aber ich denke, wir sollten einen Grund für das Suffix finden, ja es ist cool, den Namen nicht zu haben, aber es ist nicht konsistent.

Also bedeutet ZombieEntity den Entity-Typ für Zombies?

kann dieses Argument nicht auch für Blöcke verwendet werden?

Ich stimme der Konsistenz wegen nicht zu

Der Unterschied besteht darin, dass wir sagen "Ich habe 5 Steinblöcke" (nicht "5 Steine"), sondern "Ich habe 5 Schafe" (nicht "Schaf-Entitäten").

Wenn Sie sagen "Ich habe 5 Steine" bitte :+1: dieses Problem

Stellen Sie sich vor, wir nennen die Klassen SheepThing und ItemThing .

Genau das haben wir, denn "Entität" ist nur ein Synonym für "Ding" und "Objekt" .

Ist "Entität" ein Synonym für "Ding" und "Objekt"? Ja.

Bedeutet das, dass die Entität in Minecraft nicht spezifischer sein kann?

Entitäten umfassen alle dynamischen, sich bewegenden Objekte in der Minecraft-Welt.

Wären Sie dann mit den Namen SheepDynamicObject oder SheepGameObject einverstanden?

"Artikel", "Objekt" und "Ding" sind Synonyme von "Artikel" . Sollen wir SwordItem in SwordArticle , SwordObject oder SwordThing umbenennen?

Der Punkt ist, dass SheepThing und ItemThing bedeutungslose Variationen sind, wenn das Konzept einer "Entität" in Minecraft als etwas spezifischeres als ein "Ding" oder ein "Objekt" definiert ist, genau wie "Artikel".

Ich sage nicht, dass Entität bedeutungslos ist. Ich sage, dass es ein allgemeiner Begriff ist, der für alle dynamischen Dinge verwendet wird, genauso wie wir java.lang.Object , aber nicht StringObject , IntegerObject usw.

Der Punkt, den ich mit diesem Vergleich anstellen wollte, war, dass, wenn Mojang stattdessen Entity Thing hätte, Sie immer noch für SheepThing , ItemThing wären?

"Artikel", "Objekt" und "Ding" sind Synonyme von "Artikel" . Sollen wir SwordItem in SwordArticle , SwordObject oder SwordThing umbenennen?

Der Punkt ist, dass SheepThing und ItemThing bedeutungslose Variationen sind, wenn das Konzept einer "Entität" in Minecraft als etwas spezifischeres als ein "Ding" oder ein "Objekt" definiert ist, genau wie "Artikel".

Ich sehe keinen Grund, es mit Artikelnamen in Artikel oder Ding komplexer zu machen.

Shulker sind großartige Beispiele dafür, wo das Entfernen der Entitätsdenotation aufgrund eines ähnlichen Benennungsszenarios und einer Blockentität, Block- und Entitätsdefinition mit demselben Namen zu Verwirrung führen kann.

Ich sage nicht, dass Entität bedeutungslos ist. Ich sage, dass es ein allgemeiner Begriff ist, der für alle dynamischen Dinge verwendet wird, genauso wie wir java.lang.Object , aber nicht StringObject , IntegerObject usw.

java.lang.Object ist eine Superklasse jeder Klasse, und Entitätsklassen machen einen Bruchteil davon aus.

wie würden Sie beispielsweise Item von ItemEntity trennen.
Außerdem zeigt der Java-Standard EnumSet, EnumMap usw. an, sodass die Basisklasse Teil von Extendern ist
CompoundTag, ListTag, StringTag...

Das Hinzufügen des Supertyps ist gängige Praxis

Drop für die Entität für ItemType für das Registrierungselement

Die minecraft:item Registry ist ein Registry von Item , nicht ItemType , und die Entitätstyp-ID ist minecraft:item also ItemEntity .

Sicher, das Suffix Entity beizubehalten ist keine große Sache. Damit können wir leben.

Ja, bitte lass das Entity-Suffix nicht fallen. Es wird nur zu Verwirrung führen, und anstatt Dinge genau zu benennen, werden wir einfach versuchen, Dinge zu benennen, die nicht mit suffixlosen Entitäten verwechselt werden dürfen

Der Punkt, den ich mit diesem Vergleich anstellen wollte, war, dass, wenn Mojang stattdessen Entity Thing hätte, Sie immer noch für SheepThing , ItemThing wären?

Ja, denn Thing hätte in diesem Fall eine bestimmte Bedeutung.

Wie Yanis sagte, führt das Weglassen des Suffixes nur zu Verwirrung. Namen dienen der Übersichtlichkeit, nicht "gut aussehen".

Namen dienen der Übersichtlichkeit, nicht "gut aussehen".

Natürlich klingende Namen sind ebenso wichtig wie Klarheit.

Stellen Sie sich vor, ich sagte, während ich Minecraft spielte: "Ich werde einige Kuh-Entitäten töten, um rohe Rindfleischgegenstände zu erhalten, und dann einen Ofenblock verwenden, um sie in gekochte Rindfleischgegenstände zu verwandeln".

Code, der unserer Denk- und Sprechweise entspricht, ist eine sehr gute Sache.

Sie können beides gleichzeitig haben: eine natürliche Basis (Kuh, rohes Rindfleisch, Ofen) und ein klärendes Suffix (Entität, Artikel, Block).

Der Punkt ist, dass die Suffixe unnötig sind. Wir wissen, dass Kühe Wesen sind und Rindfleisch ein Gegenstand ist. Niemand sagt "Kuh-Entität" oder "Beef-Item", also warum sollten wir das sagen/lesen müssen, wenn wir Code schreiben/lesen?

es gibt immer noch das Problem von ItemEntity .

Ja, Item ist der einzige Grund, warum ich nicht sehe, dass das funktioniert. Ich würde dem wahrscheinlich nicht zustimmen, es sei denn, wir hätten Item -> ItemType aber das ist eine noch größere Umbenennung aufgrund der enormen Menge an Gegenständen im Spiel.

Die andere Option ist die Klärung, wenn Namen mehrdeutig sind, dies jedoch zu inkonsistenten Namen führt.

ItemEntity -> DroppedItem , ähnlich wie bei ThrownSnowballEntity

Wir wissen, dass Kühe Wesen sind und Rindfleisch ein Gegenstand ist. Niemand sagt "Kuh-Entität" oder "Beef-Item", also warum sollten wir das sagen/lesen müssen, wenn wir Code schreiben/lesen?

Die einzige andere Möglichkeit besteht darin, unabhängig von der Lösung inkonsistent zu sein.

Das Löschen des Suffixes würde zu Problemen mit Klassen für Inhalte aus verschiedenen Registrierungen führen. Die Basisklasse Item wird definitiv so benannt, weil es eine vollständige Registry (oder ihre Unterklassen) mit dem Bezeichner minecraft:item . Ebenso wird die Entitätsklasse ItemEntity definitiv so benannt, da ihr entsprechender Entitätstyp in der minecraft:entity_type Registrierung als minecraft:item registriert ist. Die aktuelle Klasse Item würde Item bleiben, aber die Klasse ItemEntity würde ebenfalls zu Item .

Wenn dieses spezielle Problem behoben wurde, indem der Name der letzteren Klasse in DroppedItem oder ähnlich geändert wurde, würde sie nicht mehr mit dem Bezeichner übereinstimmen. Dies ist ein Problem, da der Bezeichner eine gute Darstellung des Klassennamens ist, so dass wir das aktuelle automatische System zur Benennung von Feldern in Registrierungsinhaltsklassen und zum Hinzufügen des Registrierungssuffix zum Klassennamen haben.

Die gesamte Idee, die Suffixe zu entfernen, ist auch nicht mit dem Java-Standard vereinbar (siehe Implementierungen von List oder Map), wie bereits erwähnt .

Ich würde dem wahrscheinlich nicht zustimmen, es sei denn, wir hätten Item -> ItemType aber das ist eine noch größere Umbenennung aufgrund der enormen Menge an Gegenständen im Spiel.

Ich bin mir sicher, dass es ItemType , sobald Mojang Artikel datengesteuert herstellt, also ist es am besten, sich vorerst damit zurückzuhalten. Außerdem würde dies immer noch nicht mit der Kennung und unseren aktuellen Konventionen in Bezug auf minecraft:x_type Registrierungen vereinbar sein.

ItemEntity -> DroppedItem , ähnlich wie bei ThrownSnowballEntity

Dies wäre wiederum nicht mit Java-Standards und Yarn-Standards vereinbar. Ich bin neugierig auf jede Diskussion zu ThrownSnowballEntity obwohl der Bezeichner minecraft:snowball .

Die gesamte Idee, die Suffixe zu entfernen, ist auch nicht mit dem Java-Standard vereinbar (siehe Implementierungen von List oder Map).

Ein HashMap ist kein Hash, sondern eine Hash[-basierte] Map, und ein ArrayList ist kein Array, sondern eine Array[-basierte] Liste. Ein CowEntity ist eine Kuh. Es ist ein bisschen so, als ob wir sagen sollten, wir sollten "Kuhtier" statt "Kuh" sagen, weil wir "Bleistiftspitzer" statt "Bleistift" sagen ...

Schauen Sie sich Java-AWT an. Alles erstreckt sich über Component , aber wir haben nur Button statt ButtonComponent , Scrollbar statt ScrollbarComponent usw. Also wenn wir den Java-Standard, wir sollten Suffixe loswerden.

Wenn dieses spezielle Problem behoben wurde, indem der Name der letzteren Klasse in DroppedItem oder ähnlich geändert wurde, würde sie nicht mehr mit dem Bezeichner übereinstimmen.

Ich stimme zu, dass das Abgleichen der Bezeichner wichtig ist, um das Auffinden von Klassen zu erleichtern, aber ich verstehe nicht, warum wir es vollständig abgleichen müssen . Es ist in Ordnung, einige klärende Wörter wie Dropped hinzuzufügen.

Zwischen "passen Sie alle Bezeichner perfekt an, um meine Zwangsstörung zu erfüllen" und "Namen haben, die gut zu verwenden sind", würde ich die zweite wählen.

Ich bin mir sicher, dass es ItemType , sobald Mojang Artikel datengesteuert herstellt, also ist es am besten, sich vorerst damit zurückzuhalten

Ich denke, dass Item -> ItemType (sowie Block -> BlockType ) sehr wichtig ist und so schnell wie möglich erledigt werden sollte. Item ist einfach falsch, da es nicht für jedes Element eine Instanz der Klasse gibt. Es führt sogar dazu, dass Modding-Neulinge den Fehler machen, den Zustand des Gegenstands in Feldern in der Gegenstandsklasse zu speichern.

widerspricht dem Bezeichner und unseren aktuellen Konventionen bezüglich minecraft:x_type Registrierungen.

Diese Konvention macht keinen Sinn. Die Register speichern Elementtypen und Blocktypen, nicht die Instanzen jedes einzelnen Elements und Blocks. Die Variation der _type Suffixe ist eine Inkonsistenz von Mojang, und wir sollten sie nicht kopieren, genauso wie wir einen Tippfehler in einem Bezeichner nicht kopieren würden.

Um ehrlich zu sein, Rune, "Ich werde einige Kuhwesen töten" klingt für mich nicht weit davon entfernt, natürlich zu klingen, da ich aus der Tech-Community komme.

Wenn Sie Minecraft wie natürliche Sprache lesen möchten, gibt es viele andere Umbenennungen, die Sie tun können. "Ich werde einige Baummerkmale fällen" liest sich für niemanden gut. Bedeutet das, dass wir TreeFeature in Tree umbenennen sollten? Nein! Aber "Kuh-Entität" liest sich eigentlich gut. Besonders in einem Kontext wie "der Server verzögert, weil es viele Kuh-Entitäten an einem Ort gibt".

Bedeutet das, dass wir TreeFeature in Tree umbenennen sollten?

Ja, das Wort Feature hier ist hier überflüssig. Ich würde auch vorschlagen, Generator am Ende der Feature-Classes hinzuzufügen, da sie eigentlich Generatoren für die Features sind, nicht die Features selbst. Wir hätten so etwas wie TreeGenerator extends FeatureGenerator .

der Server verzögert sich, weil sich viele Kuh-Entitäten an einem Ort befinden

Ich vermute, Sie würden es so formulieren, um die Tatsache hervorzuheben, dass es sich um Entitäten handelt, bei denen es sich um Kühe handelt, die dem Server hinterherhinken.

Aber im Allgemeinen ist diese Betonung nicht notwendig. Wenn ich an einem regulären Mod arbeite, der nur Inhalt hinzufügt (kein Leistungsverbesserungs-Mod), würde ich darüber nachdenken, "einige Kühe zu laichen", nicht "Entitäten vom Typ Kuh hervorzubringen", und ich möchte schreiben mein Code so.

Aber sie _sind_ Kuh-Entitäten, keine Kühe. Die Idee einer Kuh existiert nur in natürlicher Sprache - CowEntity bezieht sich speziell auf die _Entität_ der Kuh, nicht das gesamte Konzept einer Kuh. Sie würden keinen Code, der sich auf andere Teile der Kuh bezieht – wie zum Beispiel ihre Drops – in diese Klasse packen.

Dieser Fahrradschuppen ist einfach nutzlos...

Das Suffix Entity ist klar, da es Sie nicht daran zweifeln lässt, "was ist diese Klasse?". Im Kontext von Minecraft ist Entity eindeutig kein Synonym für Thing .

Auch um der verdammten Modder willen, führe keine so großen Breaking Changes ein, es ist schon kompliziert genug, wenn Updates kommen, du musst es Moddern nicht noch schwerer machen, indem du ihre Workspaces fickst, weil jemand das Entity Suffix nicht mochte.

Wie sicher, ändern Sie es und sehen Sie zu, wie die ganze Welt brennt, denn jetzt kompilieren Mods aufgrund von 500 Fehlern nicht mehr. Sicher, es gibt migrationMappings, aber warum sollte ich es zur Abwechslung so bedeutungslos ausführen.

Dieses Problem ist seit 1 Jahr geöffnet und wurde nicht angewendet. Und inzwischen benutzten die Leute das Suffix Entity . Persönlich wäre ich sehr sauer, wenn eine solche Änderung zusammengeführt würde und alle meine aktuellen Mod-Arbeitsbereiche explodieren würden.

Auch die natürliche Sprache ist cool und alles, aber das ist spezifisch für die Spiel-Engine, zu versuchen, Code wie einen Roman zu lesen, ist einfach nicht möglich.

Ich muss auch nein sagen. Es gibt viele Fälle, in denen es mehrdeutig wäre (die oben genannten ItemEntity sowie ArrowEntity oder TridentEntity ).

Ich bin kein Fan dieser Idee, ich glaube nicht, dass es wirklich darauf hinausläuft, wie es in der gesprochenen Sprache gesagt wird. Es sollte über das gesamte Garn hinweg konsistent sein, und das Entfernen von nur Entitäten scheint seltsam, das Entfernen überall (Blöcke und Gegenstände) macht überhaupt keinen Sinn.

Wenn Sie sich die Abstimmung ansehen, ist es wohl klar?

Nennst du LivingEntity : Living oder Entity : nichts, das Suffix sorgt für Konsistenz mit anderen Namen, ich stimme zu, dass @l-Luna mit CowEntity nicht repräsentiert eine Kuh repräsentiert ein CowEntity , ein Cow repräsentiert die Entität, ihre Drops und ihr Model/Render-er. Die Suffixe Entity schaden niemandem, und ich denke, sie helfen für den Fall der Fälle, einige Klarstellungen hinzuzufügen, zusammen mit der Tatsache, dass BlockEntity ein verwendetes Suffix ist. Nur meine 2 Cent.

Nennen Sie LivingEntity: Living oder Entity:

Ich nenne LivingEntity ein "lebendes Wesen", also sollte dieser Name bleiben. Ich nenne CowEntity eine "Kuh", also sollte dieser Name geändert werden.

Mein Problem ist, dass Sie versuchen, Dinge so zu benennen, als ob sie nur serverseitig wären. Es wäre sicher sinnvoll, CowEntity Cow auf einer serverseitigen API zu benennen, da dies buchstäblich das gesamte Konzept von Cow for ist ein Server.

Aber hier ist auch der Client, CowEntity Cow ist schlichtweg falsch, da die Kuh definiert wird durch Entity welches das Objekt ist, das die Eigenschaften der Kuh behandelt, wie es ist interagiert mit der Welt und ihren Zielen; sondern auch durch sein Modell und seinen Renderer!

Durch die Benennung von CowEntity Cow entzieht man der Klasse einen großen Teil der Bedeutung und macht sie dann irreführend.

Ich wäre damit einverstanden, wenn das Garn nur serverseitig wäre, aber das ist es nicht.

Sogar auf dem Server repräsentiert CowEntity eine Kuh nicht vollständig, da auch Beutetabellen separat im Datenpaket gespeichert sind. Und wenn ich technisch spreche, sage ich CowEntity statt Cow . Wir erstellen kein Gameplay-Tutorial, sondern ein Set mit technischen Zuordnungen. Ja, Sie würden eine ChestBlockEntity im normalen Spielverlauf eine Truhe nennen, aber das ist kein normales Spiel, das ist Mod-Erstellung, bei der Sie ChestBlock nicht verwirren wollen. ChestBlockEntity und die Beutetabelle der Truhen. Ja, Sie sollten das Suffix beibehalten, auch wenn es für beispielsweise Creeper überflüssig ist, denn für andere Dinge ist das Suffix nicht überflüssig ( LivingEntity , Entity , ItemEntity ) und IMO es ist besser, in technischen Informationen konsistent zu sein als grammatikalisch korrekt.

Schließe dies, da die meisten dagegen sind.