Почему это переименовали?

737 #650

Я не согласен с компонентом, потому что он слишком общий.

Я все еще поддерживаю предложение игрока о Text из-за его краткости и ясности. Более того, мы уходим от других подобных двусмысленных терминов (например, Контейнер -> Предложение меню)

В вашем примере я считаю, что переименование класса TextComponentUtil в TextRenderUtil / TextRenderHelper и его метода getRenderChatMessage в handleColor является лучшим решением для переименования Класс Text .

Компонент объективно отстой. Мы проходили это десятки раз. Мы не будем повторять это снова.

@Boundarybreaker

Да, существует (мягкая) политика использования имен Mojang там, где мы их знаем, поэтому мы, вероятно, в конечном итоге переключимся на Меню и, возможно, Экран для графического интерфейса клиента.

Ясность и удобство использования всегда должны стоять на первом месте над согласованностью с Mojang. Последнее приятно иметь, но ни в коем случае не за счет первого.

Ясность и удобство использования

Вы хоть тему читали? Проблема в том, что это сбивает с толку.

Нет смысла «перебирать тексты сообщения». Имеет смысл перебирать компоненты сообщения.

существует (мягкая) политика использования имен Mojang там, где мы их знаем

ключевое слово мягкое . Если мы решим, что имя плохо для понимания, мы не будем его использовать.

Честно говоря, лично я бы тоже не выбрал Text в качестве имени. Тем не менее, это чертовски лучше, чем Component , потому что оно фактически описывает то, для чего оно используется (текст), а не является общим названием «части чего-то», которое не имеет никакого смысла вне контекста. TextComponent было бы хорошей золотой серединой, но я предполагаю, что это не совсем будет популярно, зная это сообщество.

ключевое слово мягкое.

Меню — ужасное имя, и вы хотите его использовать. (Текст)Компонент — хорошее имя, и вы не хотите его использовать.

Можете ли вы сказать мне, что имеет для вас наибольший смысл?

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

Я никогда ОДИН РАЗ не использовал итерацию над сообщением, и я сомневаюсь, что многие моддеры тоже. Я в порядке с TextComponent, но Component расплывчат и бесполезен в 99,9% случаев, когда люди действительно используют его в модах.

Нет смысла «перебирать тексты сообщения». Имеет смысл перебирать компоненты сообщения.

Тогда имеет смысл перебирать текст json или форматированный текст.

for (Component component : message) {
Проблема в том, что это не message ; это siblings вместо этого. Первый текст со всеми этими частями в потоке — это действительно весь текст в памяти.

@Boundarybreaker Yarn не просто отображает то, что вы используете.

У меня тоже нет проблем с TextComponent.

Мне нравятся и Text, и TextComponent, но Component слишком расплывчат.

Yarn — это система для понимания кода Minecraft, чтобы люди могли создавать моды, поэтому то, где и когда люди используют класс, является ключом к тому, как мы должны решить, какие имена использовать. Понятность для наиболее распространенных применений класса имеет более высокий приоритет, чем имя, которое более точно соответствует внутреннему имени Mojang.

Пряжа также используется людьми, которые хотят понять, как работает ванильный код.

Понятность для наиболее распространенных применений класса имеет более высокий приоритет, чем имя, которое более точно соответствует внутреннему имени Mojang.

Конечно, но есть имя, которое делает и то, и другое: TextComponent

На данный момент мы действительно должны рассмотреть преимущества изменения имени этого класса в третий раз.
Аргументы за его изменение:

• Чуть ближе к названию Mojang. Почему это хороший момент? Это даже не настоящее имя, так зачем беспокоиться?
• Становится понятно, что это не всегда полный текст. Это требуется? В большинстве случаев они фактически используются как полный текст, что делает Component столь же неточным. Текст может быть вложенным, ничто в его определении не говорит, что он должен быть цельным.
• Это делает поведение стиля более понятным. Это хороший момент, и его можно решить, изменив имя отдельных методов стилизации, а не имя всего класса.

Аргументы против его изменения:

• Текст короче любой альтернативы. Учитывая, как часто используется этот класс, я думаю, что это имеет значение.
• Имя этого класса менялось уже слишком много раз. Независимо от того, что мы установили, было показано, что некоторые люди будут жаловаться. Уже достаточно людей думают, что названия пряжи все время меняются ни с того ни с сего; вы должны доказать, что нынешнее название на самом деле мешает развитию и что его изменение решит все проблемы. По моему личному наблюдению, никто не жаловался на Text в обычных контекстах разработки.

Мы уже обсуждали это в Discord, поэтому я повторю свои предложения:

for (Fragment fragment : message)

И

for (TextFragment fragment : message)

Это соответствует повествованию о том, что такое сообщение. Любой фрагмент текста можно считать фрагментом, и любой текст можно разбить на другие фрагменты текста. Также в языке сегмент текста, который сам по себе не является полным предложением, если не фразой, называется «фрагментом».

Фрагмент также является куском или частью осколка. то есть _Фрагментация_.

Вы можете услышать _фрагмент_ разговора или записать его как _фрагмент_ текста. Затем разорвите страницу и выбросьте _фрагменты._

Это не значит, что я не люблю Text , меня это устраивает. Text имеет все преимущества TextFragment и даже короче. Учитывая все обстоятельства, так же хорошо, как TextFragment , _определенно_ лучше, чем TextComponent и _waaaaaaay_ лучше, чем просто Component . Я бы не изменил его.

TextFragment немного лучше, чем TextComponent , но он так же далек от названия Mojang, как Text. Я думаю, что Text действительно лучший вариант из двух.

Я бы назвал его 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 ?

Сравните это:

• Я перебираю тексты, составляющие этот текст.
• Я перебираю фрагменты текста, из которых состоит этот фрагмент текста.

Не могли бы вы проголосовать в новом выпуске? Хотя текст в майнкрафте уродлив, но в майнкрафте есть только один тип текста, поэтому я бы сказал, что названия «текст» достаточно, в то время как есть другие подобные компоненты (например, FoodComponent)