なぜこれが改名されたのですか？

737＃650

コンポーネントは一般的すぎるため、同意しません。

私は、その簡潔さと明快さのために、 Textに対するプレイヤーの提案を今でも支持しています。 さらに、他のそのようなあいまいな用語から離れています（例：コンテナ->メニューの提案）

あなたの例では、 TextComponentUtilクラスの名前をTextRenderUtil / TextRenderHelperに変更し、そのgetRenderChatMessageメソッドの名前をhandleColorに変更する方が良い解決策だと思います。 Textクラス。

コンポーネントは客観的に吸います。 私たちはこれを十数回繰り返しました。 二度とそれを乗り越えることはありません。

@Boundarybreaker

ええ、私たちが知っている場所でMojangの名前を使用するという（ソフトな）ポリシーがあるので、おそらく最終的にはMenuに切り替え、おそらくクライアントGUIのScreenに切り替えます。

明瞭さと使いやすさは、常にMojangとの一貫性よりも優先されるべきです。 後者は持っているのはいいですが、前者を犠牲にして決してありません。

明瞭さと使いやすさ

あなたもその問題を読んだことがありますか？ 問題はそれが混乱しているということです。

「メッセージのテキストを繰り返す」ことは意味がありません。 メッセージのコンポーネントを反復処理することは理にかなっています。

Mojangの名前を私たちが知っている場所で使用するという（ソフトな）ポリシーがあります

キーワードはソフトです。 名前がわかりにくいと判断した場合は使用しません。

正直なところ、私も個人的にはTextを名前として選びませんでした。 とは言うものの、それはComponentよりもはるかに優れています。なぜなら、文脈から意味をなさない「何かの一部」の総称ではなく、実際に（テキスト）に使用されるものを説明しているからです。 TextComponentは良い中間点になるでしょうが、このコミュニティを知っていると、それが必ずしも人気になるとは限らないと思います。

キーワードはソフトです。

メニューはひどい名前で、あなたはそれを使いたいです。 （Text）Componentは適切な名前であり、使用したくありません。

どちらがあなたにとって最も理にかなっているのか教えていただけますか？

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

私は一度もメッセージに対して反復を使用したことがなく、多くのmodderも使用しているとは思えません。 私はTextComponentで大丈夫ですが、Componentはあいまいで、人々が実際にModで使用する場所の99.9％では役に立ちません。

「メッセージのテキストを繰り返す」ことは意味がありません。 メッセージのコンポーネントを反復処理することは理にかなっています。

その場合、jsonテキストまたはリッチテキストを繰り返すことは理にかなっています。

for (Component component : message) {
問題は、物事がmessageではないということです。 代わりにsiblingsです。 ストリーム内のこれらすべてのサブパートを含む最初のテキストは、実際にはメモリ内のテキスト全体です。

@Boundarybreaker Yarnは、使用するものをマップするだけではありません。

TextComponentにも問題はありません。

TextとTextComponentの両方が好きですが、Componentがあいまいすぎます。

Yarnは、人々がmodを作成できるようにするためのMinecraftコードを理解するためのシステムです。したがって、人々がクラスを使用する場所とタイミングは、使用する名前を決定する方法の鍵となります。 クラスの最も一般的な使用法の理解度は、Mojangの内部名よりも正確な名前よりも優先されます。

ヤーンは、バニラコードがどのように機能するかを理解したい人にも使用されます。

クラスの最も一般的な使用法の理解度は、Mojangの内部名よりも正確な名前よりも優先されます。

もちろんですが、両方を行う名前があります： TextComponent

この時点で、このクラスの名前を3回変更することの利点を実際に検討する必要があります。
それを変更するための引数：

• mojangの名前に少し近い。 なぜこれが良い点なのですか？ 実際の名前でもないのに、なぜわざわざ？
• それは必ずしも全文ではないことを明確にします。 これは必要ですか？ ほとんどの場合、実際には全文として使用されるため、 Componentも同様に不正確になります。 テキストはネストすることができますが、その定義には、完全なものでなければならないことを示すものはありません。
• これにより、スタイルの動作がより明確になります。 これは良い点であり、クラス全体の名前ではなく、個々のスタイリングメソッドの名前を変更することで解決できます。

それを変更することに反対する議論：

• テキストは他のどの方法よりも短いです。 このクラスが使用される頻度を考えると、それは重要だと思います。
• このクラスの名前は、すでに何度も変更されています。 何に設定しても、文句を言う人がいることがわかりました。 十分な数の人々が、糸の名前は理由もなく常に変化していると考えています。 現在の名前が実際に開発を妨げていること、そしてそれを変更することですべての問題が解決することを証明する必要があります。 私の個人的な観察では、通常の開発コンテキストでは誰もTextについて不満を言っていません。

これについてはDiscordですでに説明したので、提案を繰り返します。

for (Fragment fragment : message)

と

for (TextFragment fragment : message)

これは、メッセージが何であるかという物語と一致します。 テキストのどの部分もフラグメントと見なすことができ、テキストは他のテキストのフラグメントに分割できます。 また、言語では、それ自体が完全な文ではないテキストのセグメントは、フレーズではないにしても、「フラグメント」と呼ばれます。

フラグメントは、ピースまたはパーツ、シャードでもあります。 つまり、_Fragmentation_。

会話の_断片_を聞くか、テキストの_断片_として書き留めることができます。 次に、ページを破棄して、_fragments._を破棄します。

これは、私がTextが好きではないと言っているわけではありません、私はそれで大丈夫です。 Textには、 TextFragmentのすべての利点があり、さらに短くなります。 考慮されるすべてのものは、 TextFragmentと同じくらい良く、 TextComponentよりも_間違いなく_良く、 Componentよりも_waaaaaaay_優れています。 私はそれを変えません。

TextFragmentはTextComponentよりもわずかに優れていますが、テキストのようにmojangの名前からはほど遠いです。 Textは確かに2つの優れたオプションだと思います。

TextTreeNodeという名前を付けます。これは、その動作に最も近い名前だからです。

   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

しかし、それらは実際にはツリーノードですが、ツリー全体を表示するように制限されたクラスはありません。したがって、私はTextという名前を維持しています。

さて、この議論を終わらせる時が来ました。 問題の反対の量を考えると、この問題を安全に閉じることができると思います

@liachこことDiscordに関する多くのコメントは、 Textは良い名前ではないことに同意しています。 TextComponentでない場合は、別の名前に変更する必要があります。 多分TextPiece ？

これらを比較してください：

• このテキストを構成するテキストを繰り返し処理しています。
• このテキストを構成するテキストを繰り返し処理しています。

新しい問題に投票する気ですか？ Minecraftのテキストは醜いですが、Minecraftには1種類のテキストしかないので、「text」という名前で十分ですが、他のコンポーネントのようなもの（FoodComponentなど）もあります。