Yarn: '엔티티' 접미사 삭제

이것은 BlockEntities가 아닌 일반 엔티티에 대해 Entity 를 삭제하는 것입니다.

응.

Sponge는 Entity 접미사도 사용하지 않습니다.

+1하지만 그 인수는 블록과 같은 것에도 사용할 수 없습니까? 거의 충돌하지 않습니다. 나는 블록의 아이디어를 좋아한다. 가슴하지만 엄격하게 블록과 관련되지 않은 것을 만들고 있다면 이상할 것입니다.

일관성을 위해 동의하지 않습니다

을 가진 것은 Block 접미사, IMO, 그것은 블록,하지만 블록 단지를 나타낸다는 것이다. (A)의 오직 하나의 인스턴스있다, 예를 들어 잔디를 타고 GrassBlock 그것 "이 잔디 블록이다"라고하는 것이 안전하므로, 주어진 시간에. 엔티티는 실제로 이와 같이 작동하지 않습니다. 왜냐하면 세계의 각 엔티티에 대한 엔티티 인스턴스가 있기 때문입니다. 다른 예로 좀비의 경우 "이게 좀비다"라고 말할 수 없습니다 . 좀비가 좀비입니다"라고 말하고 싶지만.

반면에 일관성 인수는 좋은 경우입니다. 일부 항목에는 해당 유형을 접미사하고 나머지 항목에는 접미사 없이 두는 것은 약간 일관성이 없습니다.

흠, 떨어지는 블록은 어떻습니까?

@Sorixelle 은 정말 좋은 지적을 합니다. 그러나 나는 우리가 접미사에 대한 이유를 찾아야 한다고 생각합니다. 예, 이름에 없는 것이 멋지지만 일관성이 없습니다.

그래서 ZombieEntity는 좀비의 Entity 유형을 의미합니까?

그 인수는 블록과 같은 것에도 사용할 수 있습니까?

일관성을 위해 동의하지 않습니다

차이점은 "나는 5개의 돌 블록이 있습니다"("5개의 돌"이 아님)라고 말하고 "나는 5개의 양이 있습니다"("양 개체"가 아님)라고 말합니다.

"나는 5개의 돌을 가지고 있습니다"라고 말하는 경우:+1: 이 문제

클래스 이름을 SheepThing 및 ItemThing 라고 상상해 보세요.

"entity"는 "thing"과 "object"의 동의어일 뿐입니다 .

"entity"는 "thing"과 "object"의 동의어인가요? 예.

그것은 엔티티가 Minecraft에서 더 구체적일 수 없다는 것을 의미합니까?

엔티티는 Minecraft 세계의 모든 동적이고 움직이는 물체를 포함합니다.

SheepDynamicObject 또는 SheepGameObject 이름으로 괜찮습니까?

"article", "object" 및 "thing"은 "item"의 동의어입니다 . SwordItem 을 SwordArticle , SwordObject 또는 SwordThing 해야 합니까?

요점은 SheepThing 및 ItemThing 는 "엔티티"의 개념이 Minecraft의 "사물" 또는 "객체"보다 더 구체적인 것으로 잘 정의될 때 의미 없는 변형이라는 것입니다. "안건".

Entity가 무의미하다고 말하는 것이 아닙니다. java.lang.Object , StringObject , IntegerObject 등이 아닌 모든 동적 사물에 사용되는 일반적인 용어입니다.

그 비교를 통해 내가 말하려고 했던 요점은 Mojang이 Entity Thing 대신 SheepThing , ItemThing 을 사용하는 것에 대해 이름을 지었다 면 ?

"article", "object" 및 "thing"은 "item"의 동의어입니다 . SwordItem 을 SwordArticle , SwordObject 또는 SwordThing 해야 합니까?

요점은 SheepThing 및 ItemThing 는 "엔티티"의 개념이 Minecraft의 "사물" 또는 "객체"보다 더 구체적인 것으로 잘 정의될 때 의미 없는 변형이라는 것입니다. "안건".

항목 이름을 기사나 물건으로 복잡하게 만들 이유가 없습니다.

Shulkers는 개체 표시를 제거하면 유사한 명명 시나리오와 동일한 이름의 블록 개체, 블록 및 개체 정의로 인해 혼동을 일으킬 수 있는 좋은 예입니다.

Entity가 무의미하다고 말하는 것이 아닙니다. java.lang.Object , StringObject , IntegerObject 등이 아닌 모든 동적 사물에 사용되는 일반적인 용어입니다.

java.lang.Object 는 모든 클래스의 슈퍼클래스이며 엔티티 클래스는 그 일부를 구성합니다.

예를 들어 Item에서 ItemEntity를 분리하는 방법은 무엇입니까?
또한 Java 표준은 EnumSet, EnumMap 등을 보여주므로 기본 클래스는 Extender의 일부입니다.
CompoundTag, ListTag, StringTag...

슈퍼 유형을 추가하는 것은 일반적인 관행입니다.

레지스트리 요소에 대한 ItemType 대한 엔티티에 대한 Drop

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 표준과 일치하지 않습니다. 식별자가 minecraft:snowball 임을 고려하더라도 ThrownSnowballEntity 에 대한 토론에 대해 궁금합니다.

접미사를 삭제한다는 전체 아이디어는 Java 표준과도 일치하지 않습니다(List 또는 Map 구현 참조).

HashMap 는 해시가 아니라 해시[기반] 맵이고 ArrayList 는 배열이 아니라 배열[기반] 목록입니다. CowEntity 는 소입니다. '연필'이 아닌 '연필 깎이'라고 하기 때문에 '소'가 아닌 '소 동물'이라고 해야 하는 것과 비슷합니다.

Java AWT를 보십시오. 모든 것이 Component 확장되지만 Button 대신 ButtonComponent , Scrollbar 대신 ScrollbarComponent 등이 있습니다. 따라서 다음을 따르면 Java 표준에서는 접미사를 제거해야 합니다.

이 특정 문제가 후자의 클래스 이름을 DroppedItem 또는 이와 유사한 것으로 변경하여 해결된 경우 더 이상 식별자와 일치하지 않습니다.

식별자를 일치시키는 것이 클래스를 쉽게 찾을 수 있도록 하는 것이 중요하다는 데 동의하지만 왜 완전히 일치시켜야 하는지 모르겠습니다. Dropped 와 같은 명확한 단어를 추가하는 것은 괜찮습니다.

"내 OCD를 만족시키기 위해 모든 식별자를 완벽하게 일치"와 "사용하기 좋은 이름을 가짐" 중에서 두 번째를 선택하겠습니다.

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_를 나타냅니다. 젖소의 다른 부분(예: 젖소)과 관련된 코드는 해당 클래스에 넣지 않습니다.

이 자전거는 그냥 쓸모가 없습니다 ...

Entity 접미사는 "이 클래스가 무엇입니까?"에 대해 의심하지 않도록 명확 합니다. Minecraft의 맥락에서 Entity 는 분명히 Thing 의 동의어가 아닙니다.

또한 빌어먹을 모더를 위해 이렇게 큰 변경 사항을 도입하지 마십시오. 업데이트가 올 때 이미 충분히 복잡합니다. 누군가 Entity 접미사를 싫어했기 때문에 작업 공간을 망쳐 모더를 더 어렵게 만들 필요가 없습니다.

확실히, 변경하고 전 세계가 불타는 것을 지켜보십시오. 이제 500 오류로 인해 모드가 컴파일되지 않기 때문입니다. 물론 migrateMappings가 있지만 왜 그렇게 의미 없는 변경을 위해 실행해야 합니까?

이 문제는 1년 동안 공개되었으며 적용되지 않았습니다. 한편 사람들은 Entity 접미사를 사용했습니다. 개인적으로 나는 그러한 변경 사항이 병합되어 현재의 모든 모드 작업 공간을 폭발시키는 것을 보고 매우 화가 났을 것입니다.

또한 ok 자연어는 멋지고 모든 것이지만 이것은 게임 엔진에만 해당하므로 소설처럼 코드를 읽으려는 것은 불가능합니다.

나도 아니라고 말해야겠다. 모호한 경우가 많이 있습니다(앞서 언급한 ItemEntity 뿐만 아니라 ArrowEntity 또는 TridentEntity ).

나는 이 아이디어의 팬이 아닙니다. 나는 그것이 실제로 그것이 구어체로 어떻게 말했는지에 달려 있다고 생각하지 않습니다. 원사 전체에서 일관성을 유지해야 하며 엔티티에서만 제거하는 것이 이상해 보이며 모든 곳(블록 및 항목)에서 제거하는 것은 전혀 의미가 없습니다.

투표를 보면 명확해 보이죠?

LivingEntity : Living 또는 Entity : 없음, 접미사는 다른 이름과 일관성을 제공합니다. CowEntity 가 있는 @l-Luna는 다음을 나타내지 않는다는 데 동의합니다. a Cow는 CowEntity , Cow 는 엔티티, 해당 방울 및 모델/렌더러를 나타냅니다. Entity 접미사는 누구에게도 피해를 주지 않으며 BlockEntity 도 사용된 접미사라는 사실과 함께 만일의 경우에 대비하여 설명을 추가하는 데 도움이 된다고 생각합니다. 그냥 내 2 센트.

LivingEntity: Living 또는 Entity:

나는 LivingEntity 를 "살아 있는 존재"라고 부르므로 그 이름은 그대로 있어야 합니다. 나는 CowEntity 를 "소"라고 부르므로 그 이름을 바꿔야 합니다.

내 문제는 서버 측 전용인 것처럼 이름을 지정하려고 한다는 것입니다. 서버 측 전용 API에서 CowEntity Cow 라는 이름을 지정하는 것은 말 그대로 암소의 전체 개념이므로 의미가 있습니다. 서버.

그러나 여기에도 클라이언트가 있습니다. CowEntity Cow 라는 이름은 소의 속성을 처리하는 개체인 Entity 의해 소가 정의되기 때문에 명백히 잘못된 것입니다. 세계 및 그 목표와 상호 작용합니다. 뿐만 아니라 모델과 렌더러에

CowEntity Cow 이름을 지정하면 클래스 의미의 큰 부분을 제거하고 오해의 소지가 있습니다.

얀이 서버측 전용이면 괜찮을 텐데 그렇지 않습니다.

서버에서도 CowEntity 는 데이터 팩에 별도로 저장된 전리품 테이블이 있기 때문에 젖소를 완전히 나타내지 않습니다. 기술적으로 이야기 할 때 그리고 내가 말할 않습니다 CowEntity 대신 Cow . 우리는 게임플레이 튜토리얼을 만드는 것이 아니라 기술적인 매핑 세트를 만들고 있습니다. 예, 일반적인 게임 플레이에서 ChestBlockEntity 를 상자라고 부를 수 있지만 이것은 일반적인 게임 플레이가 아닙니다. 이것은 ChestBlock 를 혼동하고 싶지 않은 모드 제작입니다. ChestBlockEntity 및 상자 전리품 테이블. 예, 다른 항목의 경우 접미사가 중복되지 않으므로( LivingEntity , Entity , ItemEntity ), IMO에 대해 중복되는 경우에도 접미사를 유지해야 합니다 LivingEntity 문법적으로 정확한 것보다 기술적인 정보에서 일관성을 유지하는 것이 좋습니다.

대부분의 사람들이 반대하므로 이것을 닫습니다.