Yarn: Text -> Textkomponente

Erstellt am 26. Aug. 2019  ·  23Kommentare  ·  Quelle: FabricMC/yarn

Warum wurde diese umbenannt? Komponente ist der Mojang-Name, und wenn man ihn nur „Text“ nennt, wird Code wie dieser verwirrend:

    public Text method_2164(int mouseX) {
        if (message == null) {
            return null;
        }

        int width = minecraft.textRenderer.getStringWidth(message.asFormattedString());
        int x1 = this.width / 2 - width / 2;
        int x2 = this.width / 2 + width / 2;
        int x = x1;
        if (mouseX < x1 || mouseX > x2) {
            return null;
        }

        for (Text t : message) {
            x += minecraft.textRenderer.getStringWidth(TextComponentUtil.getRenderChatMessage(t.asString(), false));
            if (x > mouseX) {
                return t;
            }
        }

        return null;
    }

Auf den ersten Blick könnte man denken, dass message eine Liste von Texten (z. B. Zeilen) ist, aber tatsächlich iteriert der Code durch die verschiedenen Komponenten von message (einfacher Text, formatierter Text , Links usw.), um die Komponente zu erhalten, über der sich die Maus befindet.

discussion refactor

Hilfreichster Kommentar

Ich habe noch nie eine Iteration über eine Nachricht verwendet, und ich bezweifle auch, dass viele Modder dies getan haben. Ich bin mit TextComponent einverstanden, aber Component ist vage und nicht hilfreich für 99,9 % der Orte, an denen es tatsächlich in Mods verwendet wird.

Alle 23 Kommentare

Warum wurde diese umbenannt?

737 #650

Ich bin mit Component nicht einverstanden, weil es zu allgemein ist.

Ich halte immer noch den Vorschlag des Spielers für Text wegen seiner Kürze und Klarheit aufrecht. Außerdem entfernen wir uns von anderen derart mehrdeutigen Begriffen (z. B. Container -> Menüvorschlag)

In Ihrem Beispiel glaube ich, dass das Umbenennen der Klasse TextComponentUtil in TextRenderUtil / TextRenderHelper und der Methode getRenderChatMessage in handleColor eine bessere Lösung für das Umbenennen ist Text Klasse.

Komponente objektiv saugt. Wir sind das ein Dutzend Mal durchgegangen. Wir gehen nicht noch einmal darauf ein.

Übersichtlichkeit und Benutzerfreundlichkeit sollten bei Mojang immer an erster Stelle stehen. Letzteres ist schön zu haben, aber niemals auf Kosten des ersteren.

Übersichtlichkeit und Benutzerfreundlichkeit

Hast du die Ausgabe überhaupt gelesen? Das Problem ist, dass es verwirrend ist.

Es macht keinen Sinn, „durch die Texte einer Nachricht zu iterieren“. Es ist sinnvoll, die Komponenten der Nachricht zu durchlaufen.

Es gibt eine (weiche) Richtlinie, Mojang-Namen zu verwenden, wo wir sie kennen

Schlüsselwort ist weich . Wenn wir entscheiden, dass ein Name schlecht für die Verständlichkeit ist, werden wir ihn nicht verwenden.

Ehrlich gesagt würde ich persönlich auch nicht Text als Namen wählen. Das heißt, es ist verdammt viel besser als Component , weil es tatsächlich beschreibt, wofür es verwendet wird (Text), anstatt ein generischer Name für "ein Stück von etwas" zu sein, das außerhalb des Kontexts keinen Sinn ergibt. TextComponent wäre ein netter Mittelweg, aber ich vermute, dass das nicht gerade beliebt sein wird, wenn man diese Community kennt.

Schlüsselwort ist weich.

Menü ist ein schrecklicher Name und Sie möchten ihn verwenden. (Text)Component ist ein guter Name und Sie möchten ihn nicht verwenden.

Können Sie mir sagen, was für Sie am sinnvollsten ist?

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

Ich habe noch nie eine Iteration über eine Nachricht verwendet, und ich bezweifle auch, dass viele Modder dies getan haben. Ich bin mit TextComponent einverstanden, aber Component ist vage und nicht hilfreich für 99,9 % der Orte, an denen es tatsächlich in Mods verwendet wird.

Es macht keinen Sinn, „durch die Texte einer Nachricht zu iterieren“. Es ist sinnvoll, die Komponenten der Nachricht zu durchlaufen.

Das Iterieren durch einen JSON-Text oder einen Rich-Text ist dann sinnvoll.

for (Component component : message) {
Das Problem ist, dass das Ding kein message ist; es ist stattdessen siblings . Der erste Text mit all diesen Unterteilen im Stream ist tatsächlich der gesamte Text im Speicher.

@Boundarybreaker Yarn bildet nicht nur ab, was Sie verwenden.

Ich habe auch kein Problem mit TextComponent.

Ich mag sowohl Text als auch TextComponent, aber Component ist zu vage.

Yarn ist ein System zum Verstehen von Minecraft-Code, damit Leute Mods erstellen können. Wo und wann Leute eine Klasse verwenden, ist also der Schlüssel dafür, wie wir entscheiden sollten, welche Namen verwendet werden sollen. Die Verständlichkeit für die häufigsten Verwendungen einer Klasse hat einen höheren Vorrang, wenn ein Name genauer dem internen Namen von Mojang entspricht.

Yarn wird auch von Leuten verwendet, die verstehen wollen, wie der Vanilla-Code funktioniert.

Die Verständlichkeit für die häufigsten Verwendungen einer Klasse hat einen höheren Vorrang, wenn ein Name genauer dem internen Namen von Mojang entspricht.

Sicher, aber es gibt einen Namen, der beides kann: TextComponent

An dieser Stelle müssen wir uns wirklich überlegen, welche Vorteile es hat, den Namen dieser Klasse zum dritten Mal zu ändern.
Argumente um es zu ändern:

  • Etwas näher am Namen von Mojang. Warum ist das ein guter Punkt? Es ist nicht einmal der eigentliche Name, also warum sich die Mühe machen?
  • Es macht deutlich, dass es sich nicht immer um den vollständigen Text handelt. Ist dies erforderlich? Meistens werden sie tatsächlich als Volltext verwendet, wodurch Component genauso ungenau wird. Text kann verschachtelt werden, nichts in seiner Definition besagt, dass es das Ganze sein muss.
  • Es macht das Verhalten des Styles klarer. Dies ist ein guter Punkt und kann gelöst werden, indem der Name der einzelnen Stilmethoden anstelle des Namens der gesamten Klasse geändert wird.

Argumente gegen eine Änderung:

  • Text ist kürzer als jede Alternative. Angesichts dessen, wie oft diese Klasse verwendet wird, denke ich, dass es wichtig ist.
  • Der Name dieser Klasse wurde bereits zu oft geändert. Egal, was wir einstellen, es hat sich gezeigt, dass sich einige Leute beschweren werden. Genug Leute denken, dass sich Garnnamen ohne Grund ständig ändern; Sie müssen beweisen, dass der aktuelle Name die Entwicklung tatsächlich behindert und dass eine Änderung jedes Problem lösen würde. Meine persönliche Beobachtung ist, dass sich in normalen Entwicklungskontexten niemand über Text beschwert hat.

Wir haben dies bereits auf Discord besprochen, also werde ich meine Vorschläge wiederholen:

for (Fragment fragment : message)

Und

for (TextFragment fragment : message)

Dies passt zu der Erzählung, was eine Nachricht ist. Jeder Text kann als Fragment betrachtet werden, und jeder Text kann in andere Textfragmente zerlegt werden. Auch in der Sprache wird ein Textsegment, das selbst kein vollständiger Satz ist, wenn nicht sogar eine Phrase, als "Fragment" bezeichnet.

Ein Fragment ist auch ein Stück oder ein Teil, eine Scherbe. dh _Fragmentierung_.

Sie können ein _Fragment_ eines Gesprächs hören oder es als _Textfragment_ aufschreiben. Zerreißen Sie dann die Seite und werfen Sie die _Fragmente_ weg.

Das soll nicht heißen, dass ich Text nicht mag, ich bin damit einverstanden. Text hat alle Vorteile von TextFragment und ist noch kürzer. Alles in allem genauso gut wie TextFragment , _definitiv_ besser als TextComponent und _waaaaaay_ besser als nur Component . Ich würde es nicht ändern.

TextFragment ist etwas besser als TextComponent , aber es ist so weit vom Mojang-Namen entfernt wie Text. Ich denke, Text ist in der Tat die bessere Option der beiden.

Ich würde es TextTreeNode nennen, da dies der Name ist, der seinem Verhalten am ehesten entspricht.

   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

Aber obwohl es sich tatsächlich um Baumknoten handelt, haben wir keine Klasse, die darauf beschränkt ist, den gesamten Baum darzustellen, daher halte ich immer noch an dem Namen Text fest.

Ok, es ist Zeit, diesen Streit zu beenden. Ich gehe davon aus, dass wir dieses Thema angesichts des großen Widerstands gegen das Thema sicher schließen können

@liach Viele Kommentare hier und Discord sind sich einig, dass Text kein guter Name ist. Wenn nicht TextComponent , sollte es in etwas anderes umbenannt werden. Vielleicht TextPiece ?

Vergleichen Sie diese:

  • Ich gehe die Texte durch, aus denen dieser Text besteht.
  • Ich iteriere durch die Textteile, aus denen dieser Textteil besteht.

Haben Sie Lust, in einer neuen Ausgabe abzustimmen? Minecraft-Text ist zwar hässlich, aber es gibt nur eine Art von Text in Minecraft, also würde ich sagen, dass der Name "Text" ausreicht, während es andere komponentenähnliche Dinge gibt (z. B. FoodComponent).

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

Runemoro picture Runemoro  ·  4Kommentare

quat1024 picture quat1024  ·  6Kommentare

haykam821 picture haykam821  ·  4Kommentare

liach picture liach  ·  4Kommentare

ChloeDawn picture ChloeDawn  ·  6Kommentare