Yarn: Largue o prefixo 'Texto' no modelo de texto

Proponho que devemos usar a nomenclatura de Mojang (quando conhecido)

Esse sempre foi um ponto um pouco controverso: alguns desenvolvedores do Fabric argumentam que os nomes devem ser melhorados quando aplicável. Eu, pessoalmente, acredito que embora os nomes oficiais sejam uma dica útil, devemos tratá-los exatamente como isso - uma dica. Além disso, não acredito que os nomes em toString sempre reflitam o nome real da classe.

De qualquer forma, sou contra, mas sou fã de verbosidade.

• "Componente" é uma palavra-chave comum que pode facilmente ser imaginada como ocorrendo em muitos padrões de conteúdo modificados, potencialmente até não muito longe do código de emissão de mensagens de bate-papo.
• Usar ou não usar "I" para marcar interfaces é, novamente, um ponto de debate - embora eu ache que geralmente decidimos usá-lo, com talvez a exceção de derivados diretos de interfaces Java (digamos, IntIterable estende Iterable).

O Fabric tende a usar prefixos comuns em todos os lugares, o que é bastante útil para o preenchimento e reconhecimento automáticos do IDE. Não usar Texto * não caberia em todo o resto.

Prefiro eliminar o infixo "Componente", ele é tecnicamente errado (o "componente" geralmente faz referência a tudo, não a uma parte ("componente") de algo) e não aumenta a legibilidade.

"Componente" é uma palavra-chave comum que pode facilmente ser imaginada como ocorrendo em muitos padrões de conteúdo modificados, potencialmente até não muito longe do código de emissão de mensagens de bate-papo.

Esse é um ponto justo, embora eu não ache que faria muita diferença (raramente é importado) - as subclasses (Texto, Pontuação, etc) eu realmente duvido que possam estar separadas de outro sistema, então não acho que isso tanto de um problema.

Usar ou não usar "I" para marcar interfaces é, novamente, um ponto de debate - embora eu ache que geralmente decidimos usá-lo, com talvez a exceção de derivados diretos de interfaces Java (digamos, IntIterable estende Iterable).

Bem, essa é uma discussão diferente, eu tenho minha preferência, mas ela pode ser discutida em outro lugar - para os propósitos desta discussão, eu ficaria feliz com Component ou IComponent .

O Fabric tende a usar prefixos comuns em todos os lugares, o que é bastante útil para o preenchimento e reconhecimento automáticos do IDE. Não usar Texto * não caberia em todo o resto.

Mesmo? Você certamente ainda obteria a conclusão para TextComponent , e eu imagino os outros também (dado o pacote, mas acho que depende do IDE).

Prefiro eliminar o infixo "Componente", ele é tecnicamente errado (o "componente" geralmente faz referência a tudo, não a uma parte ("componente") de algo) e não aumenta a legibilidade.

Só porque em muitos casos apenas um único componente é usado, não descarta que muitos possam ser usados ​​(e freqüentemente são - por exemplo, Press <x> button to jump ). O componente é uma parte essencial do nome.

Isso é, embora isso certamente esteja à parte do modelo de texto (portanto net/minecraft/text ), apenas um componente ( TextComponent ) é o texto real - o resto são espaços reservados para o cliente preencher. IMO, não faz muito sentido repetir o pacote para os componentes no nome da classe.

Eles estão todos representando um texto localizável, geralmente para ser exibido no cliente. "Texto" transmite naturalmente que pode ser embutido em si mesmo.

Se você pensar nisso de outra direção, o "componente" não tem um contêiner real, ele está sempre restrito a si mesmo até que seja consumido ou exportado para uma string. "Componente" é uma distinção desnecessária em relação a algo que não existe. Retirar "Texto" torna-o tão genérico e sem sentido quanto "Elemento", "Parte" ou similar, perdendo a descrição de sua identidade / finalidade.

Sobre o argumento do pacote: acredito que você realmente não olha os nomes dos pacotes ao ler o código ...

Sobre o argumento do pacote: acredito que você realmente não olha os nomes dos pacotes ao ler o código ...

Claro, ao ler o contexto do código é onde você saberá seu texto relacionado - o pacote só é realmente relevante durante a importação. Embora a importação seja o único caso que vejo como um problema ...

// Even when using Component in a field, context easily allows you to
// know its text-related
final Component message = new TextComponent("Hello, World!");
player.message(message);

// Each of the components are fairly easily identifiable as text
player.message(new KeybindComponent("key.jump"));
player.message(new TranslatableComponent("info.kick", "player-x"));
player.message(new ScoreComponent("name", "objective"));
player.message(new SelectorComponent("pattern"));

Dê uma olhada nos exemplos para kyori / text , para ver que mesmo sem o prefixo 'Texto' ainda é muito fácil ver o que significa e parece um pouco mais limpo também (IMO ofc).

Você pode ter um ponto com os exemplos de código, embora eu ainda argumente que ScoreComponent / SelectorComponent / KeybindComponent pode ser confuso em certos contextos.

E eu ainda não teria tanta certeza de chamar a base de "Componente". Esfrega-me da maneira errada.

E eu ainda não teria tanta certeza de chamar a base de "Componente". Esfrega-me da maneira errada.

Talvez, mas não é incomum - pegue org.w3.dom.Node por exemplo.

Eu não removeria o prefixo de texto porque o componente sozinho causaria confusão, pois há muitas classes semelhantes com os mesmos nomes

Ok, mas vamos ver o que acontece ao contrário:

// Even without Component in the name, names are still focused on the object's use
// Note that I've reversed from StringText to TextString because it flows more naturally
// in english
final Text message = new TextString("Hello, World!");
player.message(message);

// Each of these objects' purposes are easily determined without the word "Component"
player.message(new KeybindText("key.jump"));
player.message(new TranslatableText("info.kick", "player-x"));
player.message(new ScoreText("name", "objective"));
player.message(new SelectorText("pattern"));

Parece legítimo para mim.

Bem, como Kashike me lembrou - Mojang não os chama de componentes de texto - eles os chamam de componentes de bate-papo (você só precisa olhar os changelogs para saber isso).

Eles também não se referem ao componente de texto como um componente de texto de string - texto para eles é o que o tecido chama de string.

Ainda outra confirmação que mojang os chama de componentes

Minha pesquisa me levou a que estão em um pacote de bate-papo na rede pelo que vale a pena -> https://github.com/jamiemansfield/mcmap/tree/18w50a/workspace/net/minecraft/network/chat

(Editar: celular bobo)