Yarn: Eliminar sufijos de 'Entidad'

Esto es solo eliminar Entity para entidades regulares y no BlockEntities, ¿sí?

Sí.

Sponge tampoco usa sufijos Entity .

+1 pero ¿no se puede usar ese argumento también para cosas como bloques? Casi nunca choca. Me gusta la idea de los bloques. Cofre, pero si está haciendo algo que no está estrictamente relacionado con el bloque, será extraño.

No estoy de acuerdo por el bien de la coherencia

Lo que pasa con el sufijo Block , IMO, es que denota no solo un bloque, sino el bloque. Tome el césped, por ejemplo, solo hay una instancia de GrassBlock en un momento dado, por lo que es seguro decir "este es el bloque de césped". Las entidades realmente no funcionan así, porque hay una instancia de la entidad para cada una en el mundo. Entonces, como otro ejemplo, con los zombis, no se puede decir "este es el zombi", porque hay varios zombis, no solo uno. Dirías "esto es un zombi".

Por otro lado, el argumento de coherencia es un buen caso: es un poco inconsistente si agregamos un sufijo a algunas cosas con su tipo y dejamos las otras sin sufijos.

hmm, ¿qué tal la caída del bloque?

@Sorixelle tiene un muy buen punto. Pero creo que deberíamos encontrar una razón para el sufijo, sí, es genial no tenerlo en el nombre, pero no es consistente.

¿Entonces ZombieEntity significa el tipo de Entidad para zombies?

¿No se puede usar ese argumento también para cosas como bloques?

No estoy de acuerdo por el bien de la coherencia

La diferencia es que decimos "Tengo 5 bloques de piedra" (no "5 piedras"), pero "Tengo 5 ovejas" (no "entidades de ovejas").

Si dices "Tengo 5 piedras", por favor: +1: este problema

Imagínese si nombramos las clases SheepThing y ItemThing .

Eso es exactamente lo que tenemos, porque "entidad" es solo un sinónimo de "cosa" y "objeto" .

¿Es "entidad" un sinónimo de "cosa" y "objeto"? Si.

¿Eso significa que esa entidad no puede ser algo más específico en Minecraft?

Las entidades abarcan todos los objetos dinámicos y en movimiento de todo el mundo de Minecraft.

¿Estaría bien con los nombres SheepDynamicObject o SheepGameObject entonces?

"artículo", "objeto" y "cosa" son sinónimos de "artículo" . ¿Deberíamos cambiar el nombre de SwordItem a SwordArticle , SwordObject o SwordThing ?

El punto es que SheepThing y ItemThing son variaciones sin sentido cuando el concepto de una "entidad" está bien definido como algo más específico que una "cosa" o un "objeto" en Minecraft, al igual que "ít".

No estoy diciendo que Entity no tenga sentido. Estoy diciendo que es un término general que se usa para todas las cosas dinámicas, de la misma manera que tenemos java.lang.Object , pero no StringObject , IntegerObject , etc.

El punto que estaba tratando de hacer con esa comparación era que si Mojang hubiera nombrado Entity Thing , ¿aún lo estaría por tener SheepThing , ItemThing ?

"artículo", "objeto" y "cosa" son sinónimos de "artículo" . ¿Deberíamos cambiar el nombre de SwordItem a SwordArticle , SwordObject o SwordThing ?

El punto es que SheepThing y ItemThing son variaciones sin sentido cuando el concepto de una "entidad" está bien definido como algo más específico que una "cosa" o un "objeto" en Minecraft, al igual que "ít".

No veo ninguna razón para hacerlo más complejo con nombres de elementos en artículos o cosas.

Los Shulkers son excelentes ejemplos de dónde eliminar la denotación de entidad puede hacer que las cosas sean confusas debido a un escenario de nomenclatura similar y una entidad de bloque, un bloque y una definición de entidad del mismo nombre.

No estoy diciendo que Entity no tenga sentido. Estoy diciendo que es un término general que se usa para todas las cosas dinámicas, de la misma manera que tenemos java.lang.Object , pero no StringObject , IntegerObject , etc.

java.lang.Object es una superclase de cada clase, y las clases de entidad constituyen una fracción de eso.

cómo separaría Item de ItemEntity, por ejemplo.
Además, el estándar Java muestra EnumSet, EnumMap, etc., por lo que la clase base es parte de los extensores
CompoundTag, ListTag, StringTag ...

Agregar el súper tipo es una práctica común

Drop para la entidad por ItemType para el elemento de registro

El registro minecraft:item es un Registry de Item , no ItemType , y el ID del tipo de entidad es minecraft:item por lo que es ItemEntity .

Claro, mantener el sufijo Entity no es gran cosa. Podemos vivir con eso.

Sí, no suelte el sufijo de entidad, por favor. Solo generará confusión y, en lugar de nombrar las cosas con precisión, intentaremos nombrar las cosas para que no se confundan con entidades sin sufijo.

El punto que estaba tratando de hacer con esa comparación era que si Mojang hubiera nombrado Entity Thing , ¿aún lo estaría por tener SheepThing , ItemThing ?

Sí, porque Thing tendría un significado específico en ese caso.

Como dijo Yanis, eliminar el sufijo solo genera confusión. Los nombres son para mayor claridad, no para "verse bien".

Los nombres son para mayor claridad, no para "verse bien".

Los nombres que suenen naturales es tan importante como la claridad.

Imagina que dije mientras jugaba Minecraft "Voy a matar algunas entidades de vaca para obtener algunos artículos de carne cruda y luego usar un bloque de horno para convertirlos en artículos de carne cocida".

El código que coincida con la forma en que pensamos y hablamos es algo muy bueno.

Puede tener ambos al mismo tiempo: una base natural (vaca, carne cruda, horno) y un sufijo clarificador (entidad, elemento, bloque).

El caso es que los sufijos son innecesarios. Sabemos que las vacas son entidades y la carne de res es un artículo. Nadie dice "entidad de vaca" o "elemento de carne de res", entonces, ¿por qué deberíamos decir / leer eso al escribir / leer código?

todavía existe el problema de ItemEntity .

Sí, Item es la única razón por la que no veo que esto funcione. Probablemente no estaría de acuerdo con él a menos que hiciéramos Item -> ItemType pero ese es un cambio de nombre aún mayor debido a la cantidad de elementos en el juego.

La otra opción es aclarar cuándo los nombres son ambiguos pero eso hace que los nombres sean inconsistentes.

ItemEntity -> DroppedItem , similar a la forma en que tenemos ThrownSnowballEntity

Sabemos que las vacas son entidades y la carne de res es un artículo. Nadie dice "entidad de vaca" o "elemento de carne de res", entonces, ¿por qué deberíamos decir / leer eso al escribir / leer código?

La única otra opción es ser inconsistente sin importar la solución.

Eliminar el sufijo causaría problemas con las clases de contenido de diferentes registros. La clase base Item definitivamente se llama así porque existe un registro completo de ella (o sus subclases) usando el identificador minecraft:item . Asimismo, la clase de entidad ItemEntity se denomina definitivamente de esa manera porque su tipo de entidad respectivo está registrado en el registro minecraft:entity_type como minecraft:item . La clase actual Item permanecería como Item , pero la clase ItemEntity también se convertiría en Item .

Si este problema específico se resolvió cambiando el nombre de la última clase a DroppedItem o similar, entonces ya no coincidiría con el identificador. Esto es un problema, ya que hay suficiente fe en que el identificador sea una buena representación del nombre de la clase que tenemos el sistema automático actual de nombrar campos en las clases de contenido del registro y agregar el sufijo del registro al nombre de la clase.

La idea completa de eliminar los sufijos también es incompatible con el estándar Java (consulte las implementaciones de List o Map), como se mencionó anteriormente .

Probablemente no estaría de acuerdo a menos que hiciéramos Item -> ItemType pero ese es un cambio de nombre aún mayor debido a la cantidad de elementos en el juego.

Estoy seguro de que habrá un ItemType tan pronto como Mojang fabrique elementos basados ​​en datos, por lo que es mejor esperar esto por ahora. Además, esto aún sería inconsistente con el identificador y nuestras convenciones actuales con respecto a los registros minecraft:x_type .

ItemEntity -> DroppedItem , similar a la forma en que tenemos ThrownSnowballEntity

Una vez más, esto sería incompatible con los estándares de Java y los estándares de Yarn. Tengo curiosidad por cualquier discusión sobre ThrownSnowballEntity aunque considerando que su identificador es minecraft:snowball .

La idea completa de eliminar los sufijos también es incompatible con el estándar Java (consulte las implementaciones de List o Map),

Un HashMap no es un hash, sino un mapa hash [basado en], y un ArrayList no es una matriz, sino una lista de matriz [basada en]. A CowEntity es una vaca. Es un poco como decir que deberíamos decir "animal de vaca" en lugar de "vaca" porque decimos "sacapuntas" en lugar de "lápiz" ...

Mira Java AWT. Todo se extiende Component , pero solo tenemos Button lugar de ButtonComponent , Scrollbar lugar de ScrollbarComponent , etc. Estándar de Java, deberíamos deshacernos de los sufijos.

Si este problema específico se resolvió cambiando el nombre de la última clase a DroppedItem o similar, entonces ya no coincidiría con el identificador.

Estoy de acuerdo en que hacer coincidir los identificadores es importante para que las clases sean fáciles de encontrar, pero no veo por qué tenemos que hacerlo por completo . Agregar algunas palabras aclaratorias como Dropped está bien.

Entre "hacer coincidir todos los identificadores perfectamente para satisfacer mi TOC" y "tener nombres que sean agradables de usar", elegiría el segundo.

Estoy seguro de que habrá un ItemType tan pronto como Mojang fabrique elementos basados ​​en datos, por lo que es mejor esperar esto por ahora.

Creo que Item -> ItemType (así como Block -> BlockType ) es muy importante y debe hacerse lo antes posible. Item es simplemente incorrecto, ya que no hay una instancia de la clase para cada elemento. Incluso lleva a las personas nuevas en modding a cometer el error de almacenar el estado del elemento en los campos de la clase del elemento.

inconsistente con el identificador y nuestras convenciones actuales con respecto a los registros minecraft:x_type .

Esa convención no tiene sentido. Los registros almacenan tipos de elementos y tipos de bloques, no las instancias de cada elemento y bloque individual. La variación de los sufijos _type es una inconsistencia de Mojang, y no deberíamos copiarla, al igual que no copiaríamos un error tipográfico en un identificador.

Para ser honesto, Rune, "Voy a matar algunas entidades vacas" no está lejos de sonarme natural, viniendo de la comunidad tecnológica.

Si desea que Minecraft se lea como un lenguaje natural, hay muchos otros cambios de nombre que puede hacer. "Voy a talar algunas características del árbol" no se lee bien para nadie. ¿Eso significa que deberíamos cambiar el nombre de TreeFeature a Tree ? ¡No! Pero "entidad vaca" realmente se lee bien. Especialmente en un contexto como "el servidor está retrasado porque hay muchas entidades de vaca en un solo lugar".

¿Eso significa que deberíamos cambiar el nombre de TreeFeature a Tree ?

Sí, la palabra Feature aquí es redundante aquí. También sugiero agregar Generator al final de las clases de características, ya que en realidad son generadores de las características, no de las características en sí mismas. Tendríamos algo como TreeGenerator extends FeatureGenerator .

el servidor está retrasado porque hay muchas entidades de vaca en un solo lugar

Supongo que la razón por la que lo expresaría así es para poner énfasis en el hecho de que son las entidades, que resultan ser vacas, las que están rezagadas en el servidor.

Pero, en general, este énfasis no es necesario. Si estoy trabajando en un mod regular que solo agrega contenido (no un mod de mejora del rendimiento), estaría pensando en "generar algunas vacas", no "generar entidades del tipo vaca", y me gustaría escribir mi código de esa manera.

Pero son Entidades Vacas, no Vacas. La idea de una vaca solo existe en lenguaje natural: CowEntity se refiere específicamente a la _entidad_ vaca, no al concepto completo de vaca. No pondría código que se relacione con otras partes de la vaca, como sus gotas, en esa clase.

Esta bicis es simplemente inútil ...

El sufijo Entity es claro ya que no te deja dudar sobre "¿qué es esta clase?". En el contexto de Minecraft, Entity claramente no es sinónimo de Thing .

También por el amor de los modders, no introduzcas un cambio tan grande, ya es lo suficientemente complicado cuando llegan las actualizaciones, no tienes que ponérselo más difícil a los modders follando sus espacios de trabajo porque a alguien no le gustó el sufijo Entity .

Por supuesto, cámbielo y observe cómo se quema el mundo entero porque ahora los mods no se compilan debido a 500 errores. Claro que hay migrateMappings, pero ¿por qué tendría que ejecutarlo para un cambio tan insignificante ?

Este problema ha estado abierto durante 1 año y no se aplicó. Y mientras tanto, la gente usaba el sufijo Entity . Personalmente, me enojaría mucho ver que un cambio de este tipo se fusionara, lo que explotaría todos mis espacios de trabajo de mod actuales.

Además, el lenguaje natural está bien y todo eso, pero esto es específico del motor del juego, tratar de leer el código como una novela simplemente no es posible.

Yo también tendré que decir que no. Hay muchos casos en los que sería ambiguo (el mencionado ItemEntity , así como ArrowEntity o TridentEntity ).

No soy un fanático de esta idea, no creo que realmente se reduzca a cómo se dice en el lenguaje hablado. Debe ser consistente a lo largo del hilo, y quitarlo solo de las entidades parece extraño, quitarlo en todas partes (bloques y elementos) no tiene ningún sentido.

Mirando la votación, ¿supongo que está claro?

¿Llamas LivingEntity : Living o Entity : nada, el sufijo proporciona coherencia con otros nombres, estoy de acuerdo @ l-Luna con CowEntity no representa una vaca representa un CowEntity , un Cow representa la entidad, sus gotas y su modelo / renderizador. Los sufijos Entity no hacen daño a nadie, y creo que ayudan a agregar alguna aclaración por si acaso, junto con el hecho de que BlockEntity es un sufijo usado. Solo mis 2 centavos.

¿Se llama LivingEntity: Living o Entity:

Llamo a LivingEntity una "entidad viviente", por lo que ese nombre debería quedarse. Llamo a CowEntity una "vaca", por lo que ese nombre debería cambiarse.

Mi problema es que estás tratando de nombrar cosas como si fueran solo del lado del servidor, seguro nombrar CowEntity Cow en una API solo del lado del servidor tendría sentido, ya que es literalmente todo el concepto de vaca para un servidor.

Pero aquí también está el cliente, nombrar CowEntity Cow es simplemente incorrecto ya que la vaca se define por su Entity que es el objeto que maneja las propiedades de la vaca, cómo interactúa con el mundo y sus objetivos; ¡sino también por su modelo y su renderizador!

Al nombrar CowEntity Cow , eliminas una gran parte del significado de la clase y la conviertes en engañosa.

Estaría bien con esto si el hilo fuera solo del lado del servidor, pero no lo es.

Incluso en el servidor CowEntity no representa completamente una vaca, ya que también tiene tablas de botín almacenadas por separado en el paquete de datos. Y cuando hablo técnicamente, digo CowEntity lugar de Cow . No estamos haciendo un tutorial de juego, estamos haciendo un conjunto de asignaciones técnicas. Sí, llamarías a un ChestBlockEntity un cofre en un juego normal, pero esto no es un juego normal, esto es creación de mods, donde no quieres confundir ChestBlock , ChestBlockEntity y la mesa de botín de cofres. Sí, debe mantener el sufijo incluso si es redundante para, por ejemplo, creepers, porque para otras cosas el sufijo no es redundante ( LivingEntity , Entity , ItemEntity ) y en mi opinión es mejor ser coherente en la información técnica que gramaticalmente correcto.

Cerrando esto ya que la mayoría está en contra.