Yarn: 删除“实体”后缀

这只是将Entity用于常规实体而不是 BlockEntities，是吗？

是的。

Sponge 也不使用Entity后缀。

+1 但那个论点不能也用于块之类的东西吗？ 它几乎从不冲突。 我喜欢块的想法。 胸部，但如果你正在制作与方块无关的东西，那会很奇怪。

为了一致性，我不同意

带有Block后缀的东西，IMO，是它不仅表示一个块，而且表示块。 以草例如，有永远只能一个的实例GrassBlock在任何给定的时间，所以它的安全，说：“这是草块”。 实体实际上并不是这样工作的，因为世界上的每个实体都有一个实体的实例。 因此，作为另一个例子，僵尸，你不能说“这是僵尸”，因为有多个僵尸，不只是一个。 你会说“这是一个僵尸”。

另一方面，一致性论证是一个很好的例子——如果我们给一些东西加上它们的类型后缀而让其他东西没有后缀，这有点不一致。

嗯，掉落方块怎么样？

@Sorixelle提出了一个非常好的观点。 但我认为我们应该为后缀找到一个原因，是的，名称上没有这个很酷，但不一致。

所以 ZombieEntity 是指僵尸的实体类型？

那个论点不能也用于块之类的东西吗？

为了一致性，我不同意

区别在于我们说“我有 5 个石块”（不是“5 块石头”），而是“我有 5 只羊”（不是“羊实体”）。

如果您说“我有 5 块石头”，请：+1：这个问题

想象一下，如果我们将类命名为SheepThing和ItemThing 。

这正是我们所拥有的，因为“实体”只是“事物”和“对象”的同义词。

“实体”是“事物”和“对象”的同义词吗？ 是的。

这是否意味着实体在 Minecraft 中不能是更具体的东西？

实体包括整个 Minecraft 世界中所有动态的、移动的物体。

那么你会同意SheepDynamicObject或SheepGameObject的名字吗？

"article"、"object" 和 "thing" 是 "item" 的同义词。 我们应该将SwordItem重命名SwordArticle 、 SwordObject还是SwordThing ？

关键是SheepThing和ItemThing是没有意义的变体，当“实体”的概念被很好地定义为比 Minecraft 中的“事物”或“对象”更具体的东西时，就像“物品”。

我并不是说 Entity 没有意义。 我是说这是一个用于所有动态事物的通用术语，就像我们有java.lang.Object ，但不是StringObject 、 IntegerObject等。

我试图通过这种比较来说明的一点是，如果Mojang 将Entity Thing命名Entity Thing ，您还会因为SheepThing 、 ItemThing吗？

"article"、"object" 和 "thing" 是 "item" 的同义词。 我们应该将SwordItem重命名SwordArticle 、 SwordObject还是SwordThing ？

关键是SheepThing和ItemThing是没有意义的变体，当“实体”的概念被很好地定义为比 Minecraft 中的“事物”或“对象”更具体的东西时，就像“物品”。

我看不出有什么理由让它更复杂，将项目名称添加到文章或事物中。

由于相似的命名场景和同名的方块实体、方块和实体定义，潜影贝是移除实体符号会使事情变得混乱的很好的例子。

我并不是说 Entity 没有意义。 我是说这是一个用于所有动态事物的通用术语，就像我们有java.lang.Object ，但不是StringObject 、 IntegerObject等。

java.lang.Object是每个类的超类，实体类只是其中的一小部分。

例如，您将如何将 Item 与 ItemEntity 分开。
此外，Java 标准显示 EnumSet、EnumMap 等，因此基类是扩展器的一部分
复合标签、列表标签、字符串标签...

添加超类型是常见的做法

Drop用于实体ItemType用于注册表元素

minecraft:item注册表是Registry的Item ，而不是ItemType ，实体类型 ID 是minecraft:item所以它是ItemEntity 。

当然，保留Entity后缀没什么大不了的。 我们可以忍受。

是的，请不要删除实体后缀。 它只会导致混淆，而不是准确命名事物，我们只会尝试命名事物以免与无后缀实体混淆

我试图通过这种比较来说明的一点是，如果 Mojang 命名为Entity Thing ，你还会因为SheepThing ， ItemThing吗？

是的，因为在这种情况下Thing将具有特定含义。

正如 Yanis 所说，去掉后缀只会导致混淆。 名称是为了清楚起见，而不是“看起来不错”。

名称是为了清楚起见，而不是“看起来不错”。

听起来自然的名字与清晰度一样重要。

想象一下我在玩 Minecraft 时说“我要杀死一些牛实体以获得一些生牛肉物品，然后使用熔炉将它们变成熟牛肉物品”。

代码与我们思考和说话的方式相匹配是一件非常好的事情。

您可以同时拥有两者：天然基础（牛、生牛肉、熔炉）和澄清后缀（实体、物品、方块）。

关键是后缀是不必要的。 我们知道牛是实体，牛肉是一个项目。 没有人说“牛实体”或“牛肉项目”，那么我们为什么要在编写/阅读代码时说/阅读呢？

仍然存在ItemEntity 。

是的Item是我认为这不起作用的唯一原因。 我可能不会同意它，除非我们做了Item -> ItemType但由于游戏中物品的剪切量，这是一个更大的重命名。

另一种选择是在名称不明确但会导致名称不一致时进行澄清。

ItemEntity -> DroppedItem ，类似于我们有ThrownSnowballEntity

我们知道牛是实体，牛肉是一个项目。 没有人说“牛实体”或“牛肉项目”，那么我们为什么要在编写/阅读代码时说/阅读呢？

唯一的另一种选择是无论解决方案如何都不一致。

删除后缀会导致来自不同注册表的内容的类出现问题。 Item基类最终以这种方式命名，因为存在一个使用标识符minecraft:item的注册表（或其子类）。 同样， ItemEntity实体类最终以这种方式命名，因为其各自的实体类型在minecraft:entity_type注册表中注册为minecraft:item 。 当前的Item类将保留为Item ，但ItemEntity类也将变为Item 。

如果通过将后一个类的名称更改为DroppedItem或类似名称来解决此特定问题，则它将不再与标识符匹配。 这是一个问题，因为我们有足够的信心标识符是类名的良好表示，我们拥有当前在注册表内容类中命名字段的自动系统，并将注册表后缀添加到类名。

如前所述，删除后缀的整个想法也与 Java 标准不一致（参见 List 或 Map 的实现）。

我可能不会同意它，除非我们做了Item -> ItemType但由于游戏中物品的剪切量，这是一个更大的重命名。

我敢肯定，一旦 Mojang 使项目数据驱动，就会有ItemType ，所以最好暂时搁置这个。 另外，这仍然与标识符和我们当前关于minecraft:x_type注册表的约定不一致。

ItemEntity -> DroppedItem ，类似于我们有ThrownSnowballEntity

再一次，这将与 Java 标准和 Yarn 标准不一致。 我很好奇关于ThrownSnowballEntity任何讨论，尽管考虑到它的标识符是minecraft:snowball 。

删除后缀的整个想法也与 Java 标准不一致（参见 List 或 Map 的实现），

HashMap不是哈希，而是哈希[-based] 映射， ArrayList不是数组，而是数组[-based] 列表。 CowEntity是一头牛。 这有点像说我们应该说“牛动物”而不是“牛”，因为我们说的是“铅笔刀”而不是“铅笔”......

看看Java AWT。 一切都扩展Component ，但我们只有Button而不是ButtonComponent ， Scrollbar而不是ScrollbarComponent等等。所以如果我们遵循Java标准，我们应该去掉后缀。

如果通过将后一个类的名称更改为DroppedItem或类似名称来解决此特定问题，则它将不再与标识符匹配。

我同意匹配标识符对于使类易于查找很重要，但我不明白为什么我们必须完全匹配它。 添加一些澄清词，例如Dropped就可以了。

在“完美匹配所有标识符以满足我的强迫症”和“有很好用的名字”之间，我会选择第二个。

我敢肯定，一旦 Mojang 使项目数据驱动，就会有ItemType ，所以最好暂时搁置这个

我认为Item -> ItemType （以及Block -> BlockType ）非常重要，应该尽快完成。 Item是错误的，因为每个项目都没有该类的实例。 它甚至会导致不熟悉修改的人犯将项目状态存储在项目类的字段中的错误。

与标识符和我们当前关于minecraft:x_type注册表的约定不一致。

这种约定没有意义。 注册表存储项目类型和块类型，而不是每个单独的项目和块的实例。 _type后缀的变化是 Mojang 的不一致，我们不应该复制它，就像我们不会复制标识符中的拼写错误一样。

老实说，Rune 来自科技社区，“我要出去杀死一些牛实体”对我来说听起来很自然。

如果你想让 Minecraft 读起来像自然语言，你可以做很多其他的重命名。 “我要砍掉一些树的特征”对任何人来说都不好读。 这是否意味着我们应该将TreeFeature重命名Tree ？ 不！ 但“牛实体”实际上读起来很好。 尤其是在“服务器滞后，因为一个地方有很多牛实体”这样的上下文中。

这是否意味着我们应该将TreeFeature重命名Tree ？

是的，这里的Feature一词在这里是多余的。 我还建议在要素类的末尾添加Generator ，因为它们实际上是要素的生成器，而不是要素本身。 我们会有类似TreeGenerator extends FeatureGenerator 。

服务器滞后，因为一个地方有很多牛实体

我猜你这么说的原因是强调实体，恰好是奶牛，落后于服务器。

但总的来说，这种强调是没有必要的。 如果我正在开发一个只添加内容的常规模组（不是性能改进模组），我会考虑“生成一些奶牛”，而不是“生成奶牛类型的实体”，我想写我的代码就是这样。

但他们_是_奶牛实体，而不是奶牛。 牛的概念只存在于自然语言中 - CowEntity 特指牛_实体_，而不是牛的整个概念。 您不会在该类中放置与奶牛其他部分相关的代码 - 例如它的掉落物。

这个自行车棚是没用的......

Entity后缀很清楚，因为它不会让您怀疑“这个类是什么？”。 在 Minecraft 的上下文中， Entity显然不是Thing的同义词。

也为了他妈的模组制作者，不要引入这么大的破坏性更改，当更新来临时它已经足够复杂了，您不必因为有人不喜欢Entity后缀而通过他妈的工作区来增加模组制作者的难度。

当然，继续更改它，然后看着整个世界燃烧，因为现在由于 500 个错误，mods 无法编译。 当然有 migrateMappings 但为什么我必须运行它来进行如此无意义的更改。

这个issue已经开了1年了，还没申请。 同时人们使用了Entity后缀。 就我个人而言，看到这样的更改被合并从而使我当前所有的 mod 工作区爆炸，我会非常生气。

另外，好吧，自然语言很酷，但这是特定于游戏引擎的，尝试像小说一样阅读代码是不可能的。

我也不得不说不。 有很多情况下它是模棱两可的（前面提到的ItemEntity ，以及ArrowEntity或TridentEntity ）。

我不是这个想法的粉丝，我不认为它真的归结为它在口语中的表达方式。 它应该在纱线上保持一致，从实体中移除它似乎很奇怪，在任何地方（块和物品）移除它根本没有任何意义。

看看投票，猜猜看清楚了吗？

你叫LivingEntity : Living还是Entity : 没什么，后缀提供了与其他名字的一致性，我同意@l-Luna with CowEntity不代表a Cow 它代表一个CowEntity ，一个Cow代表实体、它的掉落物和它的模型/渲染器。 Entity后缀不会伤害任何人，我认为它们有助于添加一些说明以防万一，以及BlockEntity也是一个使用后缀的事实。 只有我的 2 美分。

你叫 LivingEntity：Living 还是 Entity：

我称LivingEntity为“活体”，因此该名称应保留。 我称CowEntity为“牛”，因此该名称应该更改。

我的问题是你试图命名它只是服务器端的东西，确保在服务器端 API 上命名CowEntity Cow是有意义的，因为它实际上是牛的整个概念服务器。

但是这里也有客户端，命名CowEntity Cow是完全错误的，因为牛是由Entity定义的，它是处理牛属性的对象，它是如何定义的与世界及其目标互动； 但也取决于它的模型和渲染器！

通过将CowEntity Cow命名CowEntity该类的大部分含义，您将使其具有误导性。

如果纱线只是服务器端，我会很好，但事实并非如此。

即使在服务器上CowEntity也不能完全代表一头牛，因为它也有单独存储在数据包中的战利品表。 从技术上讲，我确实说CowEntity而不是Cow 。 我们不是在制作游戏教程，而是在制作技术映射集。 是的，您会在正常游戏中将ChestBlockEntity称为宝箱，但这不是正常的游戏，这是模组制作，您不想混淆ChestBlock ， ChestBlockEntity和宝箱战利品表。 是的，你应该保留后缀，即使它对于说爬行者来说是多余的，因为对于其他东西，后缀不是多余的（ LivingEntity ， Entity ， ItemEntity ）和 IMO技术信息的一致性比语法正确更好。

关闭它，因为大多数人反对它。