Yarn: CommandBlockBlockEntity -> CommandBlockEntity

Es un CommandBlock BlockEntity no un CommandBlockBlock Entity

Pero en esa lógica, la clase CommandBlock debería llamarse CommandBlockBlock .

Tienes un punto ^^

Justa.

Personalmente, creo que debería haber un sufijo de doble bloque. Como es un bloque (Note Block), no un bloque (Note)

Pero en esa lógica, la clase CommandBlock debería llamarse CommandBlockBlock.

Creo que debería.

También son relevantes aquí los bloques grass y grass_block . No estoy seguro de cómo se nombran actualmente, pero probablemente deberían considerarse dentro de este contexto.

Estoy a favor de CommandBlockBlock

¿No es el sufijo la intención de dejar claro el tipo de clase? CommandBlock ya contiene, block, porque es un sufijo creado a partir de mojang para denotar comandos de tipo block. No es necesario el BlockBlock aquí.

Excepto que el bloque no es el sufijo; toda la clase base es. En este caso, el sufijo de cualquier subclase de BlockEntity sería BlockEntity, como con todas las demás clases base en las asignaciones actuales, y el prefijo de cada subclase de BlockEntity es el nombre de clase completo de su bloque, incluido el prefijo de ese nombre de clase. , por lo tanto, el prefijo es CommandBlock y el sufijo es BlockEntity.
La eliminación de uno de los bloques se puede leer como el prefijo CommandBlock con el sufijo Entity, lo que implica que es una subclase de Entity a primera vista; el prefijo Command con el sufijo BlockEntity, lo que implica que es el BlockEntity de un bloque llamado Command y no CommandBlock a primera vista, o simplemente como una forma abreviada de CommandBlockBlockEntity, lo que introduce ambigüedad.
Dicho esto, la mayoría de la gente debería saber a estas alturas que CommandBlocks tiene BlockEntities y no Entidades normales y que CommandBlock comienza con Command. Sin embargo, la forma actual es coherente con el resto de las asignaciones, y la coherencia facilita las cosas, incluso si no se sale de la lengua con tanta facilidad.

la forma actual es consistente con el resto de las asignaciones

No creo que lo sea, porque CommandBlock no es CommandBlockBlock . Sin embargo, tu punto sobre la ambigüedad es bueno.