Yarn: Eliminar sufixos de 'Entidade'

Isso é apenas descartar Entity para entidades regulares e não BlockEntities, certo?

Sim.

A esponja também não usa sufixos Entity .

+1, mas esse argumento também não pode ser usado para coisas como blocos? Quase nunca colide. Gosto da ideia de blocos. Baú, mas se você estiver fazendo algo que não está estritamente relacionado ao bloqueio, será estranho.

Eu discordo por uma questão de consistência

O que acontece com o sufixo Block , IMO, é que ele denota não apenas um bloco, mas o bloco. Pegue a grama, por exemplo, há apenas uma instância de GrassBlock a qualquer momento, então é seguro dizer "este é o bloco de grama". As entidades realmente não funcionam assim, porque há uma instância da entidade para cada uma no mundo. Então, como outro exemplo, com zumbis, você não pode dizer "este é o zumbi", porque existem vários zumbis, não apenas um. Você diria "este é um zumbi".

Por outro lado, o argumento de consistência é um bom caso - é um pouco inconsistente se sufocarmos algumas coisas com seu tipo e deixarmos as outras sem sufixos.

hmm, que tal um bloco em queda?

@Sorixelle fez uma

então ZombieEntity significa o tipo de entidade para zumbis?

esse argumento também não pode ser usado para coisas como blocos?

Eu discordo por uma questão de consistência

A diferença é que dizemos "Eu tenho 5 blocos de pedra" (não "5 pedras"), mas "Eu tenho 5 ovelhas" (não "entidades ovelhas").

Se você disser "Eu tenho 5 pedras", por favor: +1: este problema

Imagine se nomearmos as classes SheepThing e ItemThing .

Isso é exatamente o que temos, pois "entidade" é apenas um sinônimo para "coisa" e "objeto" .

"Entidade" é sinônimo de "coisa" e "objeto"? sim.

Isso significa que essa entidade não pode ser algo mais específico no Minecraft? Não.

As entidades abrangem todos os objetos dinâmicos e móveis em todo o mundo do Minecraft.

Você concordaria com os nomes SheepDynamicObject ou SheepGameObject então?

"artigo", "objeto" e "coisa" são sinônimos de "item" . Devemos renomear SwordItem para SwordArticle , SwordObject ou SwordThing ?

A questão é que SheepThing e ItemThing são variações sem sentido quando o conceito de uma "entidade" é bem definido como algo mais específico do que uma "coisa" ou um "objeto" no Minecraft, assim como "item".

Não estou dizendo que Entity não tem sentido. Estou dizendo que é um termo geral usado para todas as coisas dinâmicas, da mesma forma que temos java.lang.Object , mas não StringObject , IntegerObject , etc.

O que eu estava tentando fazer com essa comparação é que se Mojang tivesse nomeado Entity Thing vez disso, você ainda estaria por ter SheepThing , ItemThing ?

"artigo", "objeto" e "coisa" são sinônimos de "item" . Devemos renomear SwordItem para SwordArticle , SwordObject ou SwordThing ?

A questão é que SheepThing e ItemThing são variações sem sentido quando o conceito de uma "entidade" é bem definido como algo mais específico do que uma "coisa" ou um "objeto" no Minecraft, assim como "item".

Não vejo razão para torná-lo mais complexo com nomes de itens em artigos ou coisas.

Shulkers são ótimos exemplos de onde remover a denotação de entidade pode tornar as coisas confusas devido ao cenário de nomenclatura semelhante e uma entidade de bloco, bloco e definição de entidade com o mesmo nome.

Não estou dizendo que Entity não tem sentido. Estou dizendo que é um termo geral usado para todas as coisas dinâmicas, da mesma forma que temos java.lang.Object , mas não StringObject , IntegerObject , etc.

java.lang.Object é uma superclasse de cada classe, e as classes de entidade constituem uma fração disso.

como você separaria Item de ItemEntity, por exemplo.
Além disso, o padrão Java mostra EnumSet, EnumMap etc, portanto, a classe base faz parte dos extensores
CompoundTag, ListTag, StringTag ...

Adicionar o supertipo é uma prática comum

Drop para a entidade para ItemType para o elemento de registro

O registro minecraft:item é Registry de Item , não ItemType , e o ID do tipo de entidade é minecraft:item portanto ItemEntity .

Claro, manter o sufixo Entity não é grande coisa. Nós podemos viver com isso.

Sim, não elimine o sufixo Entity, por favor. Isso só vai levar à confusão e, em vez de nomear as coisas com precisão, vamos apenas tentar nomear as coisas para não serem confundidas com entidades sem sufixo

O que eu estava tentando fazer com essa comparação é que se Mojang tivesse nomeado Entity Thing vez disso, você ainda estaria por ter SheepThing , ItemThing ?

Sim, porque Thing teria um significado específico nesse caso.

Como disse Yanis, retirar o sufixo só leva à confusão. Os nomes são para maior clareza, não para "boa aparência".

Os nomes são para maior clareza, não para "boa aparência".

Nomes que parecem naturais são tão importantes quanto clareza.

Imagine que eu disse ao jogar Minecraft "Vou matar algumas entidades de vaca para obter alguns itens de carne crua e, em seguida, usar um bloco de forno para transformá-los em itens de carne cozida".

O código que corresponde à maneira como pensamos e falamos é uma coisa muito boa.

Você pode ter os dois ao mesmo tempo: uma base natural (vaca, carne crua, forno) e um sufixo esclarecedor (entidade, item, bloco).

A questão é que os sufixos são desnecessários. Sabemos que as vacas são entidades e a carne é um item. Ninguém diz "entidade vaca" ou "item de carne", então por que deveríamos dizer / ler isso ao escrever / ler o código?

ainda há o problema de ItemEntity .

Sim Item é a única razão pela qual não vejo isso funcionando. Eu provavelmente não concordaria com isso a menos que fizéssemos Item -> ItemType mas essa é uma renomeação ainda maior devido à quantidade de cisalhamento de itens no jogo.

A outra opção é esclarecer quando os nomes são ambíguos, mas isso faz com que os nomes sejam inconsistentes.

ItemEntity -> DroppedItem , semelhante à forma como temos ThrownSnowballEntity

Sabemos que as vacas são entidades e a carne é um item. Ninguém diz "entidade vaca" ou "item de carne", então por que deveríamos dizer / ler isso ao escrever / ler o código?

A única outra opção é ser inconsistente, não importa a solução.

Eliminar o sufixo causaria problemas com classes para conteúdo de diferentes registros. A classe base Item é definitivamente nomeada dessa forma porque existe um registro completo dela (ou de suas subclasses) usando o identificador minecraft:item . Da mesma forma, a classe de entidade ItemEntity é definitivamente nomeada dessa forma porque seu respectivo tipo de entidade está registrado no registro minecraft:entity_type como minecraft:item . A classe Item atual permaneceria como Item , mas a classe ItemEntity também se tornaria Item .

Se esse problema específico foi resolvido alterando o nome da última classe para DroppedItem ou similar, então ele não corresponderia mais ao identificador. Isso é um problema, pois há fé suficiente no identificador como uma boa representação do nome da classe, de modo que temos o sistema automático atual de nomear campos nas classes de conteúdo do registro e adicionar o sufixo do registro ao nome da classe.

Toda a ideia de eliminar os sufixos também é inconsistente com o padrão Java (consulte as implementações de Lista ou Mapa), conforme mencionado anteriormente .

Eu provavelmente não concordaria com isso a menos que fizéssemos Item -> ItemType mas essa é uma renomeação ainda maior devido à quantidade de cisalhamento de itens no jogo.

Tenho certeza de que haverá ItemType assim que a Mojang tornar os itens baseados em dados, então é melhor não fazer isso por enquanto. Além disso, isso ainda seria inconsistente com o identificador e nossas convenções atuais sobre minecraft:x_type registros.

ItemEntity -> DroppedItem , semelhante à forma como temos ThrownSnowballEntity

Mais uma vez, isso seria inconsistente com os padrões Java e Yarn. Estou curioso sobre qualquer discussão a respeito de ThrownSnowballEntity embora considerando que seu identificador seja minecraft:snowball .

Toda a ideia de eliminar os sufixos é inconsistente com o padrão Java também (consulte as implementações de Lista ou Mapa),

Um HashMap não é um hash, mas sim um mapa hash [baseado em], e um ArrayList não é uma matriz, mas sim uma lista [baseada] em matriz. A CowEntity é uma vaca. É um pouco como dizer que deveríamos dizer "animal vaca" em vez de "vaca", porque dizemos "apontador de lápis" em vez de "lápis" ...

Veja o Java AWT. Tudo se estende a Component , mas temos apenas Button vez de ButtonComponent , Scrollbar vez de ScrollbarComponent , etc. Portanto, se seguirmos o Padrão Java, devemos nos livrar dos sufixos.

Se esse problema específico foi resolvido alterando o nome da última classe para DroppedItem ou semelhante, então ele não corresponderia mais ao identificador.

Concordo que a correspondência dos identificadores é importante para facilitar a localização das classes, mas não vejo por que temos que fazer a correspondência completamente . Adicionar algumas palavras esclarecedoras como Dropped está ok.

Entre "combinar todos os identificadores perfeitamente para satisfazer meu TOC" e "ter nomes que são bons de usar", eu escolheria o segundo.

Tenho certeza de que haverá ItemType assim que Mojang tornar os itens baseados em dados, então é melhor não fazer isso por enquanto

Acho que Item -> ItemType (assim como Block -> BlockType ) é muito importante e deve ser feito o mais rápido possível. Item é simplesmente errado, já que não há uma instância da classe para cada item. Isso leva até mesmo pessoas novas em modding a cometer o erro de armazenar o estado do item em campos na classe do item.

inconsistente com o identificador e nossas convenções atuais sobre minecraft:x_type registros.

Essa convenção não faz sentido. Os registros armazenam tipos de itens e blocos, não as instâncias de cada item e bloco individual. A variação dos sufixos _type é uma inconsistência de Mojang e não devemos copiá-la, assim como não copiaríamos um erro de digitação em um identificador.

Para ser honesto, Rune, "Eu vou matar algumas entidades vacas" não está longe de soar natural para mim, vindo da comunidade de tecnologia.

Se você quiser que o Minecraft seja lido como uma linguagem natural, há muitas outras renomeações que você pode fazer. "Vou cortar algumas características da árvore" não é uma boa leitura para ninguém. Isso significa que devemos renomear TreeFeature para Tree ? Não! Mas "entidade vaca" realmente lê bem. Especialmente em um contexto como "o servidor está atrasado porque há muitas entidades vacas em um só lugar".

Isso significa que devemos renomear TreeFeature para Tree ?

Sim, a palavra Feature aqui é redundante aqui. Eu também sugiro adicionar Generator no final das classes de recursos, uma vez que eles são realmente geradores para os recursos, não os próprios recursos. Teríamos algo como TreeGenerator extends FeatureGenerator .

o servidor está atrasado porque há muitas entidades vacas em um só lugar

Suponho que o motivo pelo qual você expressou isso dessa forma é para enfatizar o fato de que são entidades, que por acaso são vacas, que estão atrasadas em relação ao servidor.

Mas, em geral, essa ênfase não é necessária. Se estou trabalhando em um mod regular que apenas adiciona conteúdo (não um mod de melhoria de desempenho), eu estaria pensando em "desovar algumas vacas", não "criar entidades do tipo vaca", e gostaria de escrever meu código dessa forma.

Mas eles _são_ entidades vacas, não vacas. A ideia de uma vaca só existe em linguagem natural - CowEntity refere-se especificamente à vaca _entidade_, não a todo o conceito de vaca. Você não colocaria um código relacionado a outras partes da vaca - como suas gotas - nessa classe.

Essa bicicleta é simplesmente inútil ...

O sufixo Entity é claro , pois não deixa você duvidar de "o que é essa classe?". No contexto do Minecraft, Entity claramente não é um sinônimo de Thing .

Além disso, pelo amor de modders, não introduza uma mudança tão importante, já é complicado o suficiente quando as atualizações chegam, você não precisa tornar as coisas mais difíceis para os modders fodendo seus espaços de trabalho porque alguém não gostou do sufixo Entity .

Com certeza, vá em frente, altere-o e observe o mundo inteiro queimar porque agora os mods não compilam por causa de 500 erros. Claro que há migrateMappings, mas por que eu teria que executá-lo para uma mudança tão sem sentido .

Esta edição está aberta há 1 ano e não foi aplicada. E, enquanto isso, as pessoas usavam o sufixo Entity . Pessoalmente, eu ficaria muito chateado em ver tal mudança sendo mesclada, explodindo todos os meus espaços de trabalho de mod atuais.

Além disso, ok, linguagem natural é legal e tudo, mas isso é específico para o motor de jogo, tentar ler o código como um romance simplesmente não é possível.

Terei que dizer não também. Existem muitos casos em que seria ambíguo (o mencionado ItemEntity , bem como ArrowEntity ou TridentEntity ).

Eu não sou um fã dessa ideia, eu não acho que realmente se resume a como é dito na linguagem falada. Deve ser consistente ao longo do fio, e removê-lo apenas de entidades parece estranho, removê-lo de todos os lugares (blocos e itens) não faz nenhum sentido.

Olhando para a votação, acha que está claro?

Você chama LivingEntity : Living ou Entity : nada, o sufixo fornece consistência com outros nomes, eu concordo que @ l-Luna com CowEntity não representa uma vaca representa CowEntity , Cow representa a entidade, seus drops e seu modelo / renderizador. Os sufixos Entity não estão prejudicando ninguém, e acho que ajudam a adicionar alguns esclarecimentos apenas para garantir, junto com o fato de que BlockEntity é um sufixo usado. Apenas meus 2 centavos.

Você chama LivingEntity: Living ou Entity:

Eu chamo LivingEntity "entidade viva", então esse nome deve permanecer. Eu chamo CowEntity "vaca", então esse nome deve ser mudado.

Meu problema é que você está tentando nomear as coisas como se fossem apenas do lado do servidor, com certeza nomear CowEntity Cow em uma API apenas do lado do servidor faria sentido, pois é literalmente todo o conceito de vaca para um servidor.

Mas aqui também há o cliente, nomear CowEntity Cow é totalmente errado, pois a vaca é definida por Entity que é o objeto que manipula as propriedades da vaca, como ele interage com o mundo e seus objetivos; mas também por seu modelo e seu renderizador!

Ao nomear CowEntity Cow você tira uma grande parte do significado da classe e a torna enganosa.

Eu estaria bem com isso se o yarn fosse apenas do lado do servidor, mas não é.

Mesmo no servidor CowEntity não representa totalmente uma vaca, pois também tem tabelas de pilhagens armazenadas separadamente no pacote de dados. E quando falo tecnicamente, digo CowEntity vez de Cow . Não estamos fazendo um tutorial de jogabilidade, estamos fazendo um conjunto de mapeamentos técnicos. Sim, você chamaria um ChestBlockEntity baú no jogo normal, mas isso não é um jogo normal, é a criação de mod, onde você não quer confundir ChestBlock , ChestBlockEntity e a mesa de pilhagem do baú. Sim, você deve manter o sufixo mesmo que seja redundante para, digamos, trepadeiras, porque para outras coisas o sufixo não é redundante ( LivingEntity , Entity , ItemEntity ) e IMO é melhor ser consistente nas informações técnicas do que gramaticalmente correto.

Fechando isso, já que a maioria é contra.