Por que isso foi renomeado?

737 #650

Eu discordo do Component porque é muito genérico.

Eu ainda defendo a sugestão do jogador para Text por sua brevidade e clareza. Além disso, estamos nos afastando de outros termos ambíguos (por exemplo, Container -> Proposta de menu)

No seu exemplo, acredito que renomear a classe TextComponentUtil para TextRenderUtil / TextRenderHelper e seu método getRenderChatMessage para handleColor é uma solução melhor para renomear Text aula.

Componente objetivamente é uma merda. Passamos por isso uma dúzia de vezes. Não vamos passar por isso novamente.

@Boundarybreaker

Sim, há uma política (soft) de usar nomes Mojang onde os conhecemos, então provavelmente vamos mudar para Menu e provavelmente Screen para guis de cliente.

Clareza e usabilidade devem sempre vir em primeiro lugar acima da consistência com a Mojang. O último é bom ter, mas nunca, nunca à custa do primeiro.

Clareza e usabilidade

Você sequer leu a questão? O problema é que é confuso.

Não faz sentido "iterar pelos textos de uma mensagem". Faz sentido iterar pelos componentes da mensagem.

há uma política (soft) de usar nomes Mojang onde os conhecemos

palavra-chave é suave . Se decidirmos que um nome é ruim para a compreensão, não o usaremos.

Honestamente, eu pessoalmente não escolheria Text como o nome. Dito isso, é muito melhor do que Component , porque na verdade descreve para o que é usado (texto) em vez de ser um nome genérico para "um pedaço de algo" que não faz sentido fora de contexto. TextComponent seria um bom meio termo, mas acho que não será exatamente popular conhecer essa comunidade.

palavra-chave é suave.

Menu é um nome terrível e você quer usá-lo. (Text)Component é um bom nome e você não quer usá-lo.

Você pode me dizer o que faz mais sentido para você?

• for (Component component : message) {
• for (Text text : message) {

Eu nunca usei uma vez iteração sobre uma mensagem, e duvido que muitos modders também tenham. Estou bem com TextComponent, mas Component é vago e inútil para 99,9% dos lugares que as pessoas realmente o usam em mods.

Não faz sentido "iterar pelos textos de uma mensagem". Faz sentido iterar pelos componentes da mensagem.

Iterar através de um texto json ou um rich text faz sentido então.

for (Component component : message) {
O problema é que a coisa não é message ; é siblings em vez disso. O primeiro texto com todas essas subpartes no fluxo é de fato o texto inteiro na memória.

@Boundarybreaker Yarn não apenas mapeia o que você usa.

Também não tenho problemas com TextComponent.

Eu gosto de Text e TextComponent, mas Component é muito vago.

O Yarn é um sistema para entender o código do Minecraft para que as pessoas possam criar mods, então onde e quando as pessoas usam uma classe é a chave para como devemos decidir quais nomes usar. A compreensão para os usos mais comuns de uma classe tem maior precedência para um nome ser mais preciso para o nome interno da Mojang.

O Yarn também é usado por pessoas que querem entender como o código vanilla funciona.

A compreensão para os usos mais comuns de uma classe tem maior precedência para um nome ser mais preciso para o nome interno da Mojang.

Claro, mas há um nome que faz as duas coisas: TextComponent

Neste ponto, realmente temos que considerar os benefícios de alterar o nome dessa classe pela terceira vez.
Argumentos para alterá-lo:

• Um pouco mais próximo do nome de mojang. Por que isso é um bom ponto? Não é mesmo o nome real, então por que se preocupar?
• Deixa mais claro que nem sempre é o texto completo. Isso é necessário? Na maioria das vezes, eles são usados ​​como texto completo, tornando Component igualmente impreciso. O texto pode ser aninhado, nada em sua definição afirma que deve ser a coisa completa.
• Isso torna o comportamento do estilo mais claro. Este é um bom ponto, e pode ser resolvido alterando o nome dos métodos de estilo individuais em vez do nome de toda a classe.

Argumentos contra a mudança:

• O texto é mais curto do que qualquer alternativa. Dada a frequência com que essa classe é usada, acho que isso importa.
• O nome desta classe já foi alterado muitas vezes. Não importa o que definirmos, foi demonstrado que algumas pessoas reclamarão. Muitas pessoas pensam que os nomes dos fios mudam o tempo todo sem motivo; você tem que provar que o nome atual realmente atrapalha o desenvolvimento e que mudá-lo resolveria todos os problemas. Minha observação pessoal é que ninguém reclamou de Text em contextos regulares de desenvolvimento.

Já discutimos isso no Discord, então vou reiterar minhas sugestões:

for (Fragment fragment : message)

E

for (TextFragment fragment : message)

Isso se encaixa com a narrativa do que é uma mensagem. Qualquer pedaço de Texto pode ser considerado um fragmento, e qualquer Texto pode ser dividido em outros fragmentos de texto. Também na linguagem, um segmento de texto que não é uma frase completa, se não uma frase, é chamado de "fragmento".

Um fragmento também é um pedaço, ou uma parte, um fragmento. ou seja, _Fragmentação_.

Você pode ouvir um _Fragmento_ de uma conversa ou escrevê-lo como um _Fragmento_ de texto. Então rasgue a página e jogue fora os _fragmentos._

Isso não quer dizer que eu não goste de Text , estou bem com isso. Text tem todos os benefícios de TextFragment e é ainda mais curto. Tudo considerado, tão bom quanto TextFragment , _definitely_ melhor que TextComponent e _waaaaaaay_ melhor que apenas Component . Eu não mudaria.

TextFragment é um pouco melhor que TextComponent , mas está tão longe do nome mojang quanto Text. Acho que Text é de fato a opção superior dos dois.

Eu o chamaria de TextTreeNode , pois esse é o nome que mais combina com seu comportamento.

   TextTreeNode setStyle(Style var1);

   Style getStyle();

   TextTreeNode addChild(String string_1);

   TextTreeNode addChild(TextTreeNode var1);

   String getContent(); // only self

   String getString(); // whole tree, overrides brigadier message api, no format

   String getString(int maxLength); // whole tree, truncated result possibly

   String getFormattedString(); // whole tree

   List<TextTreeNode> getChildren();

   Stream<TextTreeNode> streamTree();

   Stream<TextTreeNode> streamCopiedTreeNodes();

   Iterator<TextTreeNode> treeIterator();

   TextTreeNode copy(); // copy this node

   TextTreeNode formattedDeepCopy(); // copy the whole tree with style

   TextTreeNode format(Consumer<Style> consumer_1); // accept the style

   TextTreeNode format(Formatting... formattings_1); // mutates the node

   TextTreeNode format(Formatting formatting_1); // mutates the node

   static TextTreeNode formattedCopy(TextTreeNode text_1); // copy this node with style

Mas mesmo que eles sejam de fato nós de árvore, não temos uma classe restrita a apresentar a árvore inteira, portanto, ainda defendo o nome Text .

Ok, é hora de acabar com este argumento. Suponho que podemos encerrar esta questão com segurança, dada a quantidade de oposição da questão

@liach Muitos comentários aqui e no Discord concordam que Text não é um bom nome. Se não for TextComponent , deve ser renomeado para outra coisa. Talvez TextPiece ?

Compare estes:

• Estou iterando pelos textos que compõem este texto.
• Estou iterando através dos pedaços de texto que compõem este pedaço de texto.

Importa-se de fazer um voto em uma nova edição? Embora o texto do minecraft seja feio, mas há apenas um tipo de texto no minecraft, então eu diria que o nome "texto" é suficiente, enquanto existem outras coisas semelhantes a componentes (por exemplo, FoodComponent)