Yarn: 文本 -> 文本组件

创建于 2019-08-26  ·  23评论  ·  资料来源: FabricMC/yarn

这个为什么改名了? Component 是 Mojang 的名称,仅将其称为“文本”会使这样的代码令人困惑:

    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;
    }

快速看一下,您可能会认为message是文本列表(例如行),但实际上,代码正在迭代message的不同组件(纯文本,样式文本,链接等)来获取鼠标所在的组件

discussion refactor

最有用的评论

我从来没有在消息上使用过迭代,而且我怀疑许多模组制作者也有。 我对 TextComponent 很好,但是对于人们在 mod 中实际使用它的 99.9% 的地方来说,Component 是模糊且无用的。

所有23条评论

这个为什么改名了?

737 #650

我不同意 Component,因为它太通用了。

我仍然支持玩家对Text的建议,因为它简洁明了。 此外,我们正在远离其他此类模棱两可的术语(例如 Container -> Menu proposal)

在您的示例中,我相信将TextComponentUtil类重命名为TextRenderUtil / TextRenderHelper并将其getRenderChatMessage方法重命名为handleColor是重命名的更好解决方案Text类。

组件客观上很糟糕。 我们经历了十几次。 我们不再赘述。

清晰度和可用性应该始终高于与 Mojang 的一致性。 后者很好,但绝不以牺牲前者为代价。

清晰度和可用性

你甚至读过这个问题吗? 问题是它令人困惑。

“遍历消息文本”是没有意义的。 遍历消息的组件确实有意义。

有使用我们知道的 Mojang 名称的(软)政策

关键字是soft 。 如果我们认为一个名称不利于理解,我们就不会使用它。

老实说,我个人也不会选择Text作为名称。 也就是说,它比Component好得多,因为它实际上描述了它的用途(文本),而不是作为“一件东西”的通用名称,这在上下文中是零意义的。 TextComponent将是一个不错的中间地带,但我猜想知道这个社区不会很受欢迎。

关键字是软的。

菜单是一个可怕的名字,你想使用它。 (Text)Component 是个好名字,你不想用它。

你能告诉我哪个对你最有意义吗?

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

我从来没有在消息上使用过迭代,而且我怀疑许多模组制作者也有。 我对 TextComponent 很好,但是对于人们在 mod 中实际使用它的 99.9% 的地方来说,Component 是模糊且无用的。

“遍历消息文本”是没有意义的。 遍历消息的组件确实有意义。

遍历 json 文本或富文本是有意义的。

for (Component component : message) {
问题是这东西不是message ; 它是siblings 。 流中包含所有这些子部分的第一个文本确实是内存中的整个文本。

@Boundarybreaker Yarn 不仅仅映射你使用的东西。

我对 TextComponent 也没有问题。

Text 和 TextComponent 我都喜欢,但是 Component 太模糊了。

Yarn 是一个用于理解 Minecraft 代码以便人们能够创建 mod 的系统,因此人们在何时何地使用一个类是我们应该如何决定使用什么名称的关键。 类的最常见用途的可理解性优先于更准确的 Mojang 内部名称的名称。

Yarn 也被想要了解普通代码如何工作的人使用。

类的最常见用途的可理解性优先于更准确的 Mojang 内部名称的名称。

当然可以,但是有一个名称可以兼得: TextComponent

这时候我们真的要考虑第三次改这个类名的好处了。
改变它的论据:

  • 稍微接近mojang的名字。 为什么这是一个好点? 它甚至不是实际名称,所以为什么要打扰?
  • 它更清楚地表明它并不总是全文。 这是必需的吗? 大多数情况下,它们实际上被用作全文,使得Component一样不准确。 文本可以嵌套,其定义中没有任何内容表明它必须是完整的。
  • 它使 Style 的行为更加清晰。 这是一个好点,可以通过更改单个样式方法的名称而不是整个类的名称来解决。

反对改变它的论点:

  • 文本比任何替代都短。 考虑到这个类的使用频率,我认为这很重要。
  • 此类的名称已更改太多次。 无论我们将其设置为什么,都表明有些人会抱怨。 已经有足够多的人认为纱线名称一直在无缘无故地改变; 您必须证明当前名称实际上阻碍了发展,并且更改它可以解决所有问题。 我个人的观察是,在常规开发环境中没有人抱怨Text

我们已经在 Discord 上讨论过这个问题,所以我将重申我的建议:

for (Fragment fragment : message)

for (TextFragment fragment : message)

这符合消息是什么的叙述。 任何一段文本都可以被认为是一个片段,任何文本都可以分解成其他的文本片段。 同样在语言中,如果不是一个短语,它本身不是一个完整句子的一段文本称为“片段”。

Fragment 也是一块或一部分,一个碎片。 即_碎片化_。

您可以听到对话的_片段_,或将其写为文本的_片段_。 然后撕掉页面并扔掉_fragments._

这并不是说我不喜欢Text ,我很好。 Text具有TextFragment的所有优点,而且更短。 考虑到所有因素,和TextFragment一样好,_肯定_ 比TextComponent好,_waaaaaaaay_ 比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)

此页面是否有帮助?
0 / 5 - 0 等级