Yarn: Supprimer les suffixes « Entité »

Il s'agit simplement de supprimer Entity pour les entités régulières et non pour les BlockEntities, n'est-ce pas ?

Ouais.

Sponge n'utilise pas non plus les suffixes Entity .

+1 mais cet argument ne peut-il pas aussi être utilisé pour des choses comme les blocs ? Il n'y a presque jamais de conflit. J'aime l'idée des blocs. Coffre, mais si vous faites quelque chose qui n'est pas strictement lié au bloc, ce sera étrange.

Je ne suis pas d'accord par souci de cohérence

Le truc avec le suffixe Block , IMO, c'est qu'il ne désigne pas seulement un bloc, mais le bloc. Prenez l'herbe, par exemple, il n'y a qu'une seule instance d'un GrassBlock à un moment donné, il est donc prudent de dire « c'est le bloc d'herbe ». Les entités ne fonctionnent pas vraiment comme ça, car il y a une instance de l'entité pour chacune dans le monde. Donc, comme autre exemple, avec les zombies, vous ne pouvez pas dire "c'est le zombie", car il y a plusieurs zombies, pas un seul. Vous diriez "c'est un zombie".

D'un autre côté, l'argument de cohérence est un bon argument - c'est un peu incohérent si nous suffixons certaines choses avec leur type et laissons les autres sans suffixes.

hmm, qu'en est-il de la chute de bloc ?

@Sorixelle fait un très bon point. Mais je pense que nous devrions trouver une raison au suffixe, oui c'est cool de ne pas avoir sur le nom, mais ce n'est pas cohérent.

donc ZombieEntity signifie le type d'entité pour les zombies ?

cet argument ne peut-il pas également être utilisé pour des choses comme les blocs ?

Je ne suis pas d'accord par souci de cohérence

La différence est que l'on dit « J'ai 5 blocs de pierre » (pas « 5 pierres »), mais « J'ai 5 moutons » (pas des « entités moutons »).

Si vous dites "J'ai 5 pierres" s'il vous plaît :+1: ce problème

Imaginez si nous nommions les classes SheepThing et ItemThing .

C'est exactement ce que nous avons, car "entité" n'est qu'un synonyme de "chose" et "objet" .

« entité » est-il synonyme de « chose » et « objet » ? Oui.

Cela signifie-t-il que l'entité ne peut pas être quelque chose de plus spécifique dans Minecraft ?

Les entités englobent tous les objets dynamiques et mobiles du monde Minecraft.

Seriez-vous d'accord avec les noms SheepDynamicObject ou SheepGameObject alors ?

"article", "objet" et "chose" sont des synonymes de "item" . Doit-on renommer SwordItem en SwordArticle , SwordObject ou SwordThing ?

Le fait est que SheepThing et ItemThing sont des variations dénuées de sens lorsque le concept d'"entité" est bien défini comme quelque chose de plus spécifique qu'une "chose" ou un "objet" dans Minecraft, tout comme "Objet".

Je ne dis pas que l'entité n'a pas de sens. Je dis que c'est un terme général qui est utilisé pour toutes les choses dynamiques, de la même manière que nous avons java.lang.Object , mais pas StringObject , IntegerObject , etc.

Le point que j'essayais de faire valoir par cette comparaison était que si Mojang avait nommé Entity Thing place, seriez-vous toujours pour avoir SheepThing , ItemThing ?

"article", "objet" et "chose" sont des synonymes de "item" . Doit-on renommer SwordItem en SwordArticle , SwordObject ou SwordThing ?

Le fait est que SheepThing et ItemThing sont des variations dénuées de sens lorsque le concept d'"entité" est bien défini comme quelque chose de plus spécifique qu'une "chose" ou un "objet" dans Minecraft, tout comme "Objet".

Je ne vois pas de raison de le rendre plus complexe avec des noms d'éléments dans un article ou une chose.

Les Shulkers sont d'excellents exemples où la suppression de la dénotation d'entité peut rendre les choses confuses en raison d'un scénario de nommage similaire et d'une entité de bloc, d'un bloc et d'une définition d'entité du même nom.

Je ne dis pas que l'entité n'a pas de sens. Je dis que c'est un terme général qui est utilisé pour toutes les choses dynamiques, de la même manière que nous avons java.lang.Object , mais pas StringObject , IntegerObject , etc.

java.lang.Object est une superclasse de chaque classe, et les classes d'entités en constituent une fraction.

comment sépareriez-vous Item de ItemEntity, par exemple.
De plus, la norme Java montre EnumSet, EnumMap, etc., la classe de base fait donc partie des extensions
CompoundTag, ListTag, StringTag...

L'ajout du super type est une pratique courante

Drop pour l'entité pour ItemType pour l'élément de registre

Le registre minecraft:item est un Registry de Item , pas ItemType , et l'ID de type d'entité est minecraft:item donc c'est ItemEntity .

Bien sûr, garder le suffixe Entity n'est pas grave. Nous pouvons vivre avec ça.

Ouais, ne laissez pas tomber le suffixe d'entité s'il vous plaît. Cela ne fera que prêter à confusion, et au lieu de nommer les choses avec précision, nous essaierons simplement de nommer les choses à ne pas confondre avec des entités sans suffixe

Le point que j'essayais de faire valoir par cette comparaison était que si Mojang avait nommé Entity Thing place, seriez-vous toujours pour avoir SheepThing , ItemThing ?

Oui, car Thing aurait une signification particulière dans ce cas.

Comme l'a dit Yanis, laisser tomber le suffixe ne fait que prêter à confusion. Les noms sont pour plus de clarté, pas pour « bien paraître ».

Les noms sont pour plus de clarté, pas pour « bien paraître ».

Des noms qui sonnent naturellement sont tout aussi importants que la clarté.

Imaginez que j'ai dit en jouant à Minecraft "Je vais tuer des entités de vache pour obtenir des éléments de bœuf cru, puis utiliser un bloc de four pour les transformer en éléments de bœuf cuit".

Un code correspondant à notre façon de penser et de parler est une très bonne chose.

Vous pouvez avoir les deux à la fois : une base naturelle (vache, bœuf cru, four) et un suffixe clarifiant (entité, article, bloc).

Le fait est que les suffixes sont inutiles. Nous savons que les vaches sont des entités et que le bœuf est un article. Personne ne dit « entité de vache » ou « élément de bœuf », alors pourquoi devrions-nous dire/lire cela lors de l'écriture/la lecture du code ?

il y a toujours le problème de ItemEntity .

Oui, Item est la seule raison pour laquelle je ne vois pas cela fonctionner. Je ne serais probablement pas d'accord à moins que nous ayons fait Item -> ItemType mais c'est un renom encore plus important en raison de la quantité d'objets dans le jeu.

L'autre option est la clarification lorsque les noms sont ambigus mais que les noms sont incohérents.

ItemEntity -> DroppedItem , similaire à la façon dont nous avons ThrownSnowballEntity

Nous savons que les vaches sont des entités et que le bœuf est un article. Personne ne dit « entité de vache » ou « élément de bœuf », alors pourquoi devrions-nous dire/lire cela lors de l'écriture/la lecture du code ?

La seule autre option est d'être incohérent, quelle que soit la solution.

La suppression du suffixe entraînerait des problèmes avec les classes pour le contenu de différents registres. La classe de base Item est définitivement nommée ainsi car il en existe un registre rempli (ou ses sous-classes) utilisant l'identifiant minecraft:item . De même, la classe d'entité ItemEntity est définitivement nommée de cette façon car son type d'entité respectif est enregistré dans le registre minecraft:entity_type sous le nom minecraft:item . La classe Item resterait Item , mais la classe ItemEntity deviendrait également Item .

Si ce problème spécifique était résolu en changeant le nom de cette dernière classe en DroppedItem ou similaire, alors il ne correspondrait plus à l'identifiant. C'est un problème car il y a suffisamment de confiance dans l'identifiant comme étant une bonne représentation du nom de classe pour que nous ayons le système automatique actuel de nommage des champs dans les classes de contenu de registre et d'ajout du suffixe de registre au nom de classe.

L'idée même de supprimer les suffixes est également incompatible avec la norme Java (voir les implémentations de List ou Map), comme mentionné précédemment .

Je ne serais probablement pas d'accord à moins que nous ne fassions Item -> ItemType mais c'est un renom encore plus important en raison de la quantité d'objets dans le jeu.

Je suis sûr qu'il y aura un ItemType dès que Mojang créera des éléments basés sur les données, il est donc préférable de ne pas en tenir compte pour le moment. De plus, cela serait toujours incompatible avec l'identifiant et nos conventions actuelles concernant les registres minecraft:x_type .

ItemEntity -> DroppedItem , semblable à la façon dont nous avons ThrownSnowballEntity

Encore une fois, cela serait incompatible avec les normes Java et les normes Yarn. Je suis curieux de connaître toute discussion concernant ThrownSnowballEntity bien que son identifiant soit minecraft:snowball .

L'idée même de supprimer les suffixes est également incompatible avec la norme Java (voir les implémentations de List ou Map),

Un HashMap n'est pas un hachage, mais plutôt une carte de hachage[-basée], et un ArrayList n'est pas un tableau, mais plutôt une liste [-basée] sur un tableau. Un CowEntity est une vache. C'est un peu comme dire qu'il faut dire « vache animal » plutôt que « vache » car on dit « taille-crayon » plutôt que « crayon »…

Regardez Java AWT. Tout s'étend sur Component , mais nous avons juste Button plutôt que ButtonComponent , Scrollbar plutôt que ScrollbarComponent , etc. Donc, si nous suivons le Java standard, nous devrions nous débarrasser des suffixes.

Si ce problème spécifique était résolu en changeant le nom de cette dernière classe en DroppedItem ou similaire, alors il ne correspondrait plus à l'identifiant.

Je suis d'accord que la correspondance des identifiants est importante pour rendre les classes faciles à trouver, mais je ne vois pas pourquoi nous devons les faire correspondre complètement . L'ajout de mots de clarification tels que Dropped est ok.

Entre "faire correspondre parfaitement tous les identifiants pour satisfaire mon TOC" et "avoir des noms agréables à utiliser", je choisirais le second.

Je suis sûr qu'il y aura un ItemType dès que Mojang créera des éléments basés sur les données, il est donc préférable de ne pas en tenir compte pour le moment

Je pense que Item -> ItemType (ainsi que Block -> BlockType ) est très important et devrait être fait dès que possible. Item est tout simplement faux, car il n'y a pas d'instance de la classe pour chaque élément. Cela amène même des personnes novices en modding à commettre l'erreur de stocker l'état de l'élément dans les champs de la classe d'élément.

incompatible avec l'identifiant et nos conventions actuelles concernant les registres minecraft:x_type .

Cette convention n'a pas de sens. Les registres stockent les types d'éléments et les types de blocs, et non les instances de chaque élément et bloc individuel. La variation sur les suffixes _type est une incohérence de Mojang, et nous ne devrions pas la copier, tout comme nous ne copierions pas une faute de frappe dans un identifiant.

Pour être honnête, Rune, "Je sors pour tuer des entités de vache" n'est pas loin de me sembler naturel, venant de la communauté technologique.

Si vous voulez que Minecraft soit lu comme un langage naturel, vous pouvez faire beaucoup d'autres renommages. "Je vais abattre certaines fonctionnalités de l'arbre" ne se lit bien pour personne. Cela signifie-t-il que nous devrions renommer TreeFeature en Tree ? Non! Mais "l'entité vache" se lit bien. Surtout dans un contexte comme "le serveur est à la traîne car il y a beaucoup d'entités vaches au même endroit".

Cela signifie-t-il que nous devrions renommer TreeFeature en Tree ?

Oui, le mot Feature ici est redondant ici. Je suggérerais également d'ajouter Generator à la fin des classes d'entités, car ce sont en fait des générateurs pour les caractéristiques, pas les caractéristiques elles-mêmes. Nous aurions quelque chose comme TreeGenerator extends FeatureGenerator .

le serveur est à la traîne car il y a beaucoup d'entités vache au même endroit

Je suppose que la raison pour laquelle vous le formuleriez ainsi est de mettre l'accent sur le fait que ce sont des entités, qui se trouvent être des vaches, qui sont à la traîne du serveur.

Mais en général, cet accent n'est pas nécessaire. Si je travaille sur un mod régulier qui ajoute simplement du contenu (pas un mod d'amélioration des performances), je penserais à "engendrer des vaches", pas à "engendrer des entités du type vache", et je voudrais écrire mon code de cette façon.

Mais ils _are_ Entités vache, pas vaches. L'idée d'une vache n'existe qu'en langage naturel - CowEntity fait spécifiquement référence à l'_entité_ vache, pas au concept entier d'une vache. Vous ne mettriez pas de code qui se rapporte à d'autres parties de la vache - comme ses gouttes - dans cette classe.

Ce hangar à vélos ne sert à rien...

Le suffixe Entity est clair car il ne vous laisse pas douter de "qu'est-ce que cette classe ?". Dans le contexte de Minecraft, Entity n'est clairement pas synonyme de Thing .

Aussi pour l'amour des putains de moddeurs, n'introduisez pas de changement aussi important, c'est déjà assez compliqué lorsque les mises à jour arrivent, vous n'avez pas à compliquer la tâche des moddeurs en baisant leurs espaces de travail parce que quelqu'un n'aimait pas le suffixe Entity .

Comme bien sûr, allez-y, changez-le et regardez le monde entier brûler car maintenant les mods ne compilent plus à cause de 500 erreurs. Bien sûr, il y a migrateMappings, mais pourquoi devrais-je l'exécuter pour un changement si dénué de sens .

Cette question est ouverte depuis 1 an, et elle n'a pas été appliquée. Et pendant ce temps, les gens utilisaient le suffixe Entity . Personnellement, je serais très énervé de voir un tel changement fusionné exploser ainsi tous mes espaces de travail de mod actuels.

De plus, d'accord, le langage naturel est cool et tout, mais c'est spécifique au moteur de jeu, essayer de lire le code comme un roman n'est tout simplement pas possible.

Je vais devoir dire non aussi. Il y a beaucoup de cas où cela serait ambigu (le ItemEntity susmentionné, ainsi que ArrowEntity ou TridentEntity ).

Je ne suis pas fan de cette idée, je ne pense pas que cela se résume vraiment à la façon dont cela est dit dans la langue parlée. Il doit être cohérent sur l'ensemble du fil, et le supprimer uniquement des entités semble étrange, le supprimer partout (blocs et éléments) n'a aucun sens.

En regardant le vote, devinez-vous que c'est clair ?

Appelez-vous LivingEntity : Living ou Entity : rien, le suffixe assure la cohérence avec d'autres noms, je suis d'accord @l-Luna avec CowEntity ne représente pas une vache représente un CowEntity , un Cow représente l'entité, ses gouttes et son modèle/render-er. Les suffixes Entity ne font de mal à personne, et je pense qu'ils aident à ajouter des éclaircissements juste au cas où, ainsi que le fait que BlockEntity est également un suffixe utilisé. Juste mes 2 cents.

Appelez-vous LivingEntity : Living ou Entity :

J'appelle LivingEntity une "entité vivante", donc ce nom devrait rester. J'appelle CowEntity une "vache", donc ce nom devrait être changé.

Mon problème est que vous essayez de nommer des choses comme si elles étaient côté serveur uniquement, bien sûr, nommer CowEntity Cow sur une API côté serveur uniquement aurait du sens car c'est littéralement le concept entier de vache pour un serveur.

Mais ici il y a aussi le client, nommer CowEntity Cow est complètement faux car la vache est définie par c'est Entity qui est l'objet gérant les propriétés de la vache, comment il interagit avec le monde et ses objectifs ; mais aussi par son modèle et son moteur de rendu !

En nommant CowEntity Cow vous enlevez une grande partie du sens de la classe et la rendez alors trompeuse.

Je serais d'accord avec cela si le fil était uniquement côté serveur, mais ce n'est pas le cas.

Même sur le serveur, CowEntity ne représente pas entièrement une vache car il a également des tables de butin stockées séparément dans le data-pack. Et quand je parle techniquement, je dis CowEntity au lieu de Cow . Nous ne faisons pas de tutoriel de gameplay, nous faisons un ensemble de mappages techniques. Oui, vous appelleriez un ChestBlockEntity un coffre dans un jeu normal, mais ce n'est pas un jeu normal, c'est de la création de mods, où vous ne voulez pas confondre ChestBlock , ChestBlockEntity et la table de butin du coffre. Oui, vous devez conserver le suffixe même s'il est redondant pour les creepers, car pour d'autres choses, le suffixe n'est pas redondant ( LivingEntity , Entity , ItemEntity ), et IMO il vaut mieux être cohérent dans l'information technique que grammaticalement correct.

Fermeture car la plupart sont contre.