这个为什么改名了? 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
的不同组件(纯文本,样式文本,链接等)来获取鼠标所在的组件。
这个为什么改名了?
我不同意 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
这时候我们真的要考虑第三次改这个类名的好处了。
改变它的论据:
Component
一样不准确。 文本可以嵌套,其定义中没有任何内容表明它必须是完整的。反对改变它的论点:
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)
最有用的评论
我从来没有在消息上使用过迭代,而且我怀疑许多模组制作者也有。 我对 TextComponent 很好,但是对于人们在 mod 中实际使用它的 99.9% 的地方来说,Component 是模糊且无用的。