Yarn: Удалите суффиксы Entity

Это просто отбрасывает Entity для обычных объектов, а не для BlockEntities, да?

Ага.

Sponge также не использует суффиксы Entity .

+1, но нельзя ли этот аргумент также использовать для таких вещей, как блоки? В нем почти не бывает столкновений. Мне нравится идея блоков. Сундук, но если вы делаете что-то, что строго не связано с блоками, это будет странно.

Я не согласен ради последовательности

Вещь с Block суффикса, IMO, является то , что оно обозначает не только блок, но блок. Возьмите траву, например, есть только когда - либо один экземпляр GrassBlock в любой момент времени, так что с уверенностью сказать , «это трава блок». Сущности на самом деле так не работают, потому что для каждой в мире есть экземпляр сущности. Таким образом, в качестве другого примера, с зомби, вы не можете сказать «это зомби», потому что есть несколько зомби, а не только один. Вы бы сказать «это зомби».

С другой стороны, аргумент согласованности является хорошим аргументом - он немного непоследователен, если мы добавляем суффиксы к некоторым вещам с их типом и оставляем другие без суффиксов.

хм, а как насчет падающего блока?

@Sorixelle действительно хорошо

так что ZombieEntity означает тип Entity для зомби?

нельзя ли использовать этот аргумент и для таких вещей, как блоки?

Я не согласен ради последовательности

Разница в том, что мы говорим: «У меня 5 каменных блоков» (не «5 камней»), а «У меня 5 овец» (а не «сущности овец»).

Если вы скажете «У меня 5 стоун», пожалуйста: +1: эта проблема

Представьте, что мы назвали классы SheepThing и ItemThing .

Это именно то, что у нас есть, потому что «сущность» - это просто синоним «вещи» и «объекта» .

Является ли «сущность» синонимом «вещи» и «объекта»? да.

Означает ли это, что эта сущность не может быть чем-то более конкретным в Minecraft?

Сущности включают в себя все динамические движущиеся объекты в мире Minecraft.

Вы бы согласились с именами SheepDynamicObject или SheepGameObject тогда?

«артикль», «объект» и «вещь» являются синонимами «предмета» . Следует переименовать SwordItem в SwordArticle , SwordObject или SwordThing ?

Дело в том, что SheepThing и ItemThing являются бессмысленными вариациями, когда понятие «сущность» хорошо определяется как нечто более конкретное, чем «вещь» или «объект» в Minecraft, как и "пункт".

Я не говорю, что Entity бессмысленна. Я говорю, что это общий термин, который используется для всех динамических вещей, точно так же, как у нас есть java.lang.Object , но не StringObject , IntegerObject и т. Д.

Суть этого сравнения заключалась в том, что если бы Mojang вместо этого назвал Entity Thing , вы бы по-прежнему были за то, чтобы иметь SheepThing , ItemThing ?

«артикль», «объект» и «вещь» являются синонимами «предмета» . Следует переименовать SwordItem в SwordArticle , SwordObject или SwordThing ?

Дело в том, что SheepThing и ItemThing являются бессмысленными вариациями, когда понятие «сущность» хорошо определяется как нечто более конкретное, чем «вещь» или «объект» в Minecraft, как и "пункт".

Я не вижу причин усложнять задачу с названиями предметов в статье или предмете.

Shulkers - отличные примеры того, где удаление обозначения сущности может сбить с толку из-за схожего сценария именования и определения сущности, блока и сущности с тем же именем.

Я не говорю, что Entity бессмысленна. Я говорю, что это общий термин, который используется для всех динамических вещей, точно так же, как у нас есть java.lang.Object , но не StringObject , IntegerObject и т. Д.

java.lang.Object - это суперкласс каждого класса, и классы сущностей составляют его часть.

как, например, отделить Item от ItemEntity.
Кроме того, стандарт Java показывает EnumSet, EnumMap и т. Д., Поэтому базовый класс является частью расширителей
CompoundTag, ListTag, StringTag ...

Добавление супертипа - обычная практика

Drop для объекта для ItemType для элемента реестра

Реестр minecraft:item - это Registry из Item , а не ItemType , а идентификатор типа объекта - minecraft:item так что это ItemEntity .

Конечно, сохранить суффикс Entity нетрудно. Мы можем с этим жить.

Да, пожалуйста, не бросайте суффикс Entity. Это только приведет к путанице, и вместо того, чтобы точно называть вещи, мы просто попытаемся называть вещи, чтобы их не путали с сущностями без суффиксов.

Суть этого сравнения заключалась в том, что если бы Mojang вместо этого назвал Entity Thing , вы бы все равно остались за SheepThing , ItemThing ?

Да, потому что в этом случае Thing будет иметь особое значение.

Как сказал Янис, отказ от суффикса приведет только к путанице. Имена даны для ясности, а не для того, чтобы «хорошо выглядеть».

Имена даны для ясности, а не для того, чтобы «хорошо выглядеть».

Естественное звучание имен так же важно, как и ясность.

Представьте, что я сказал во время игры в 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 - это не хеш, а скорее карта [на основе хэша], а ArrayList - это не массив, а список [на основе массива]. CowEntity - корова. Это немного похоже на то, что мы должны говорить «корова», а не «корова», потому что мы говорим «точилка для карандашей», а не «карандаш» ...

Посмотрите на Java AWT. Все расширяет Component , но у нас просто Button вместо ButtonComponent , Scrollbar вместо ScrollbarComponent и т. Д. Стандарт Java, нам следует избавиться от суффиксов.

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

Я согласен с тем, что сопоставление идентификаторов важно для упрощения поиска классов, но я не понимаю, почему мы должны сопоставить его полностью . Можно добавить несколько уточняющих слов, например Dropped .

Я бы выбрал второе между «идеально сопоставить все идентификаторы, чтобы удовлетворить мое ОКР» и «иметь имена, которые приятно использовать».

Я уверен, что как только Mojang сделает элементы на основе данных, будет выпадать ItemType , так что пока лучше воздержаться от этого.

Я думаю, что Item -> ItemType (а также Block -> BlockType ) очень важны и должны быть выполнены как можно скорее. Item просто неверно, поскольку не существует экземпляра класса для каждого элемента. Это даже приводит к тому, что люди, плохо знакомые с моддингом, совершают ошибку, сохраняя состояние элемента в полях в классе элемента.

несовместимы с идентификатором и нашими текущими соглашениями относительно реестров minecraft:x_type .

Это соглашение не имеет смысла. В реестрах хранятся типы элементов и типы блоков, а не экземпляры каждого отдельного элемента или блока. Вариант суффиксов _type - это несоответствие Mojang, и мы не должны копировать его, как мы не копируем опечатку в идентификаторе.

Честно говоря, Рун: «Я собираюсь убить несколько коровьих существ» звучит для меня не так уж и естественно, поскольку он исходит из технического сообщества.

Если вы хотите, чтобы Minecraft читался как естественный язык, вы можете сделать множество других переименований. «Я собираюсь срубить некоторые элементы дерева» никому не подходит. Означает ли это, что мы должны переименовать TreeFeature в Tree ? Нет! Но «корова сущность» на самом деле хорошо читается. Особенно в контексте вроде «сервер отстает, потому что в одном месте много сущностей коровы».

Означает ли это, что мы должны переименовать TreeFeature в Tree ?

Да, слово Feature здесь излишне. Я также предлагаю добавить Generator в конце классов объектов, поскольку они на самом деле являются генераторами функций, а не сами функции. У нас получилось бы что-то вроде TreeGenerator extends FeatureGenerator .

сервер отстает, потому что в одном месте много сущностей коровы

Я предполагаю, что причина, по которой вы это назвали так, состоит в том, чтобы акцентировать внимание на том факте, что это сущности, которые оказываются коровами, отстают от сервера.

Но в целом такой упор не нужен. Если я работаю над обычным модом, который просто добавляет контент (а не над модом повышения производительности), я бы подумал о «порождении коров», а не «порождении сущностей типа корова», и я бы хотел написать мой код таким образом.

Но они - коровы, а не коровы. Идея коровы существует только на естественном языке - CowEntity конкретно относится к сущности коровы, а не ко всему понятию коровы. Вы не стали бы помещать в этот класс код, который относится к другим частям коровы - например, к ее дропам.

Этот велосипедный навес просто бесполезен ...

Суффикс Entity понятен, так как не позволяет сомневаться в том, «что это за класс?». В контексте Minecraft Entity явно не является синонимом Thing .

Кроме того, ради гребаного моддера, не вводите столь серьезное критическое изменение, это уже достаточно сложно, когда приходят обновления, вам не нужно усложнять работу моддеров, трахая их рабочие пространства, потому что кому-то не понравился суффикс Entity .

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

Этот выпуск открыт на 1 год и не применялся. А тем временем люди использовали суффикс Entity . Лично я был бы очень зол, если бы такое изменение было объединено, взорвав все мои текущие рабочие области модов.

Кроме того, естественный язык - это круто, но это специфично для игрового движка, пытаться читать код, как роман, просто невозможно.

Мне тоже придется сказать нет. Есть много случаев, когда это будет неоднозначно (вышеупомянутые ItemEntity , а также ArrowEntity или TridentEntity ).

Я не фанат этой идеи, я не думаю, что это действительно сводится к тому, как это сказано на устной речи. Он должен быть единообразным по всей пряжи, и удаление его только из объектов кажется странным, удаление его повсюду (блоки и элементы) вообще не имеет никакого смысла.

Глядя на голосование, угадайте, что все ясно?

Вы называете LivingEntity : Living или Entity : ничего, суффикс обеспечивает согласованность с другими именами, я согласен, что @ l-Luna с CowEntity не представляет Корова представляет собой CowEntity , Cow представляет сущность, ее капли и ее модель / рендеринг. Суффиксы Entity никому не вредит, и я думаю, они помогают добавить некоторые пояснения на всякий случай, наряду с тем фактом, что BlockEntity является используемым суффиксом. Только мои 2 цента.

Вы называете LivingEntity: Living или Entity:

Я называю LivingEntity «живым существом», так что это имя должно остаться. Я называю CowEntity "коровой", так что это имя следует изменить.

Моя проблема в том, что вы пытаетесь называть вещи так, как будто это было только на стороне сервера, убедитесь, что имя CowEntity Cow на стороне сервера API имело бы смысл, поскольку это буквально вся концепция коровы для сервер.

Но здесь также есть клиент, имя CowEntity Cow явно неверно, поскольку корова определяется ее Entity который является объектом, обрабатывающим свойства коровы, как это взаимодействует с миром и его целями; но также по его модели и рендереру!

Называя CowEntity Cow вы теряете большую часть значения класса и вводите его в заблуждение.

Я бы согласился с этим, если бы yarn была только на стороне сервера, но это не так.

Даже на сервере CowEntity не полностью представляет корову, поскольку у нее также есть таблицы добычи, хранящиеся отдельно в пакете данных. И когда я говорю технически, я говорю CowEntity вместо Cow . Мы не делаем учебник по игровому процессу, мы делаем набор технических сопоставлений. Да, вы бы назвали ChestBlockEntity сундуком в обычном игровом процессе, но это не обычный игровой процесс, это создание модов, где вы не хотите путать ChestBlock , ChestBlockEntity и таблица добычи сундуков. Да, вы должны сохранить суффикс, даже если он избыточен, скажем, для ползунов, потому что для других вещей суффикс не является избыточным ( LivingEntity , Entity , ItemEntity ) и IMO лучше быть последовательным в технической информации, чем грамматически правильным.

Закрытие, так как большинство против.