Yarn: Supprimer le préfixe « Texte » dans le modèle de texte

Je propose que nous utilisions le nom de Mojang (lorsqu'il est connu)

Cela a toujours été un point controversé : certains développeurs Fabric soutiennent que les noms devraient plutôt être améliorés, le cas échéant. Personnellement, je pense que même si les noms officiels sont un indice utile, nous devrions les traiter comme cela - un indice. De plus, je ne crois pas que les noms dans toString reflètent toujours le nom de classe réel.

De toute façon, je suis contre, mais je suis un adepte de la verbosité.

• « Composant » est un mot-clé commun qui peut facilement être imaginé comme se produisant dans de nombreux modèles de contenu modifiés, potentiellement même non loin du code émettant des messages de discussion.
• Utiliser ou ne pas utiliser "I" pour marquer les interfaces est, encore une fois, un sujet de débat - même si je pensais que nous nous sommes généralement contentés de l'utiliser, à l'exception peut-être des dérivés directs des interfaces Java (par exemple, IntIterable étend Iterable).

Fabric a tendance à utiliser des préfixes communs partout, ce qui est très utile pour la complétion et la reconnaissance automatiques de l'IDE. Ne pas utiliser Text* ne conviendrait pas à tout le reste.

Je préfère laisser tomber l'infixe "Composant", c'est techniquement faux (le "composant" fait généralement référence à l'ensemble, pas à une partie ("composant") de quelque chose) et n'ajoute rien à la lisibilité.

« Composant » est un mot-clé commun qui peut facilement être imaginé comme se produisant dans de nombreux modèles de contenu modifiés, potentiellement même non loin du code émettant des messages de discussion.

C'est un point juste, même si je ne pense pas que cela ferait une trop grande différence (c'est rarement importé) - les sous-classes (Texte, Score, etc.) Je doute vraiment qu'il puisse s'agir d'un autre système, donc je ne pense pas que ce soit tellement un problème.

Utiliser ou ne pas utiliser "I" pour marquer les interfaces est, encore une fois, un sujet de débat - même si je pensais que nous nous sommes généralement contentés de l'utiliser, à l'exception peut-être des dérivés directs des interfaces Java (par exemple, IntIterable étend Iterable).

Eh bien, c'est une discussion différente, j'ai ma préférence mais cela peut être discuté ailleurs - pour les besoins de cette discussion, je serais heureux avec soit Component soit IComponent .

Fabric a tendance à utiliser des préfixes communs partout, ce qui est très utile pour la complétion et la reconnaissance automatiques de l'IDE. Ne pas utiliser Text* ne conviendrait pas à tout le reste.

Vraiment? Vous obtiendriez certainement toujours l'achèvement pour TextComponent , et j'imagine les autres aussi (étant donné le package, mais je suppose que cela dépend de l'IDE).

Je préfère laisser tomber l'infixe "Composant", c'est techniquement faux (le "composant" fait généralement référence à l'ensemble, pas à une partie ("composant") de quelque chose) et n'ajoute rien à la lisibilité.

Ce n'est pas parce que, dans de nombreux cas, qu'un seul composant est utilisé, que plusieurs peuvent être utilisés (et le sont fréquemment - par exemple Press <x> button to jump ). Le composant est une partie essentielle du nom.

Cette chose est, bien que cela soit certainement à part du modèle de texte (d'où net/minecraft/text ), un seul composant ( TextComponent ) est du texte réel - le reste est des espaces réservés que le client doit remplir. OMI, cela n'a pas trop de sens de répéter le package pour les composants dans le nom de la classe.

Ils représentent tous du texte localisable, généralement à afficher sur le client. « Texte » exprime naturellement qu'il peut être intégré à lui-même.

Si vous y réfléchissez dans l'autre sens, le "composant" n'a pas de véritable conteneur, il est toujours contraint à lui-même jusqu'à ce qu'il soit consommé ou exporté dans une chaîne. "Composant" est une distinction inutile envers quelque chose qui n'existe pas. Supprimer le « Texte » le rend aussi générique et dépourvu de sens que « Élément », « Partie » ou similaire, perdant la description de son identité/but.

À propos de l'argument du package : je pense que vous ne regardez pas vraiment les noms des packages lorsque vous lisez du code...

À propos de l'argument du package : je pense que vous ne regardez pas vraiment les noms des packages lorsque vous lisez du code...

Bien sûr, lors de la lecture du contexte du code, vous connaissez son texte - le package n'est vraiment pertinent que lors de l'importation. Bien que l'importation soit le seul cas, je vois que c'est un problème de toute façon...

// 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"));

Jetez un œil aux exemples pour kyori/text , pour voir que même sans le préfixe 'Text', il est toujours très facile de voir ce que cela signifie et a l'air beaucoup plus propre aussi (IMO ofc).

Vous avez peut-être raison avec les exemples de code, même si je dirais toujours que ScoreComponent/SelectorComponent/KeybindComponent peut prêter à confusion dans certains contextes.

Et je ne serais toujours pas si sûr d'appeler la base "Composant". Me frotte dans le mauvais sens.

Et je ne serais toujours pas si sûr d'appeler la base "Composant". Me frotte dans le mauvais sens.

Peut-être, mais ce n'est pas rare - prenez org.w3.dom.Node par exemple.

Je ne supprimerais pas le préfixe de texte car le composant seul causerait de la confusion car il existe de nombreuses classes similaires portant les mêmes noms

D'accord mais regardons ce qui se passe à l'inverse :

// 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"));

Cela me semble légitime.

Eh bien, comme me l'a rappelé kashike - Mojang ne les appelle pas des composants de texte - ils les appellent des composants de chat (il suffit de regarder les journaux des modifications pour le savoir).

Ils ne font pas non plus référence au composant de texte en tant que composant de texte de chaîne - le texte pour eux est ce que Fabric appelle chaîne.

Encore une autre confirmation que mojang les appelle des composants

Mes recherches m'ont amené qui sont dans un package de chat en réseau pour ce que ça vaut -> https://github.com/jamiemansfield/mcmap/tree/18w50a/workspace/net/minecraft/network/chat

(Modifier : mobile stupide)