Yarn: 'エンティティ'サフィックスを削除します

これは、BlockEntitiesではなく通常のエンティティのEntityをドロップしているだけですよね？

うん。

SpongeはEntityサフィックスも使用しません。

+1ですが、その引数はブロックなどにも使用できませんか？ 衝突することはほとんどありません。 私はブロックのアイデアが好きです。 チェストですが、厳密にブロックに関連しないものを作成している場合、それは奇妙になります。

一貫性のために同意しません

事Blockサフィックスは、IMO、それはブロックが、ブロックだけでなく、を示していることです。 例えば草を取り、1つのインスタンスしかありますGrassBlock 、それは「これは草ブロックである」と言っても安全ですので、任意の時点で。 エンティティは実際にはこのようには機能しません。これは、世界の各エンティティにエンティティのインスタンスがあるためです。 だから、他の例としては、ゾンビで、あなたは1つだけでなく、複数のゾンビがあるので、「これはゾンビです」と言うことはできません。 あなたは「これはゾンビである」と言うだろう。

一方、一貫性の引数は良いケースになります-いくつかのものにそれらのタイプを接尾辞として付け、他のものに接尾辞を付けないままにしておくと、少し矛盾します。

うーん、フォーリングブロックはどうですか？

@Sorixelleは本当に良い点を示しています。 しかし、接尾辞の理由を見つける必要があると思います。名前を付けないのはクールですが、一貫性がありません。

つまり、ZombieEntityはゾンビのエンティティタイプを意味しますか？

その議論はブロックのようなものにも使用できませんか？

一貫性のために同意しません

違いは、「私は5つの石のブロックを持っている」（「5つの石」ではない）と言うのに対し、「私は5つの羊を持っている」（「羊の実体」ではない）と言うことです。

あなたが「私は5つの石を持っています」と言うなら：+ 1：この問題

クラスにSheepThingとItemThingという名前を付けたと想像してみてください。

「エンティティ」は「モノ」と「オブジェクト」の同義語にすぎないため、これがまさに私たちの持っている

「エンティティ」は「モノ」と「オブジェクト」の同義語ですか？ はい。

それは、エンティティがMinecraftでより具体的なものになることはできないということですか？

エンティティには、Minecraftの世界全体で動的に移動するすべてのオブジェクトが含まれます。

SheepDynamicObjectまたはSheepGameObjectという名前でよろしいですか？

「article」、「object」、「thing」は「item」の同義語です。 SwordItem名前をSwordArticle 、 SwordObjectまたはSwordThingますか？

重要なのは、「エンティティ」の概念がMinecraftの「モノ」や「オブジェクト」よりも具体的なものとして明確に定義されている場合、 SheepThingとItemThingは無意味なバリエーションであるということです。 "アイテム"。

エンティティが無意味だと言っているのではありません。 これは、すべての動的なものに使用される一般的な用語であり、 java.lang.Objectと同じように使用されますが、 StringObject 、 IntegerObjectなどは使用されません。

その比較で私が言いたかったのは、 Mojangが代わりにEntity Thingと名付けた場合でも、 SheepThing 、 ItemThingを持っているということ

「article」、「object」、「thing」は「item」の同義語です。 SwordItem名前をSwordArticle 、 SwordObjectまたはSwordThingますか？

重要なのは、「エンティティ」の概念がMinecraftの「モノ」や「オブジェクト」よりも具体的なものとして明確に定義されている場合、 SheepThingとItemThingは無意味なバリエーションであるということです。 "アイテム"。

アイテム名を記事や物に複雑にする理由はわかりません。

Shulkersは、エンティティの表記を削除すると、同様の命名シナリオと同じ名前のブロックエンティティ、ブロック、およびエンティティの定義が原因で混乱を招く可能性がある場合の優れた例です。

エンティティが無意味だと言っているのではありません。 これは、すべての動的なものに使用される一般的な用語であり、 java.lang.Objectと同じように使用されますが、 StringObject 、 IntegerObjectなどは使用されません。

java.lang.Objectはすべてのクラスのスーパークラスであり、エンティティクラスはその一部を構成します。

たとえば、ItemをItemEntityからどのように分離しますか。
また、Java標準ではEnumSet、EnumMapなどが示されているため、基本クラスはエクステンダーの一部です。
CompoundTag、ListTag、StringTag..。

スーパータイプの追加は一般的な方法です

レジストリ要素のItemTypeのエンティティのDrop

minecraft:itemレジストリでRegistryのItem 、ではないItemType 、およびエンティティタイプIDはminecraft:itemがあるので、 ItemEntity 。

もちろん、 Entityサフィックスを維持することは大したことではありません。 私たちはそれと一緒に暮らすことができます。

ええ、エンティティのサフィックスを削除しないでください。 混乱を招くだけで、正確に名前を付けるのではなく、接尾辞のないエンティティと混同しないように名前を付けようとします。

その比較で私が言いたかったのは、Mojangが代わりにEntity Thingと名付けた場合でも、 SheepThing 、 ItemThingを持っているということ

はい、その場合、 Thingは特定の意味を持つためです。

ヤニスが言ったように、接尾辞を削除すると混乱を招くだけです。 名前はわかりやすくするためのものであり、「見栄え」を表すものではありません。

名前はわかりやすくするためのものであり、「見栄え」を表すものではありません。

自然に聞こえる名前は、明快さと同じくらい重要です。

Minecraftをプレイしているときに、「牛の実体を殺して生の牛肉アイテムを入手し、かまどを使って調理済みの牛肉アイテムに変える」と言ったと想像してみてください。

私たちの考え方や話し方に一致するコードは非常に良いことです。

両方を同時に持つことができます：天然ベース（牛、生の牛肉、かまど）と明確な接尾辞（エンティティ、アイテム、ブロック）。

重要なのは、接尾辞は不要だということです。 牛は実体であり、牛肉はアイテムです。 「牛の実体」や「牛肉のアイテム」とは誰も言わないのに、コードを書いたり読んだりするときに、なぜそれを言わなければならないのでしょうか。

ItemEntityの問題はまだあります。

ええ、 Itemが、これが機能していない唯一の理由です。 Item -> ItemTypeを実行しない限り、おそらく同意しませんが、ゲーム内のアイテムの量が非常に多いため、これはさらに大きな名前変更になります。

もう1つのオプションは、名前があいまいであるが名前に一貫性がない場合を明確にすることです。

ItemEntity -> DroppedItem 、 ThrownSnowballEntityと同じように

牛は実体であり、牛肉はアイテムです。 「牛の実体」や「牛肉のアイテム」とは誰も言わないのに、コードを書いたり読んだりするときに、なぜそれを言わなければならないのでしょうか。

他の唯一のオプションは、解決策に関係なく一貫性を欠くことです。

サフィックスを削除すると、異なるレジストリのコンテンツのクラスで問題が発生します。 Item基本クラスは、識別子minecraft:itemを使用して、それ（またはそのサブクラス）でいっぱいのレジストリが存在するため、そのように明確に名前が付けられています。 同様に、 ItemEntityエンティティクラスは、それぞれのエンティティタイプがminecraft:entity_typeレジストリにminecraft:itemとして登録されているため、このように明確に名前が付けられています。 現在のItemクラスはItemですが、 ItemEntityクラスもItemます。

後者のクラスの名前をDroppedItemなどに変更することでこの特定の問題が解決された場合、識別子とは一致しなくなります。 レジストリコンテンツクラスのフィールドに名前を付け、レジストリサフィックスをクラス名に追加する現在の自動システムがあるため、識別子がクラス名の適切な表現であるという十分な信頼があるため、これは問題です。

サフィックスを落とすの全体のアイデアは、（リストや地図の実装を参照）と同様のJava標準と矛盾している前述のように。

Item -> ItemTypeを実行しない限り、おそらく同意しませんが、ゲーム内のアイテムの量が非常に多いため、これはさらに大きな名前変更になります。

Mojangがアイテムをデータ駆動型にするとすぐにItemTypeになると確信しているので、今のところこれを保留するのが最善です。 さらに、これは、識別子およびminecraft:x_typeレジストリに関する現在の規則とは依然として矛盾します。

ItemEntity -> DroppedItem 、 ThrownSnowballEntityと同じように

繰り返しになりますが、これはJava標準およびYarn標準と矛盾します。 識別子がminecraft:snowball考慮すると、 ThrownSnowballEntityに関する議論に興味があります。

接尾辞を削除するという全体的な考え方は、Java標準とも矛盾しています（リストまたはマップの実装を参照）。

HashMapはハッシュではなく、ハッシュ[ベース]マップであり、 ArrayListは配列ではなく、配列[ベース]リストです。 CowEntityは牛です。 「鉛筆削り」ではなく「鉛筆削り」と言うので、「牛」ではなく「牛の動物」と言うのと少し似ています。

JavaAWTを見てください。 すべてが拡張Component 、私たちはただ持っているButtonではなくButtonComponent 、 ScrollbarではなくScrollbarComponent私たちが従っている場合などだから、 Java標準では、サフィックスを削除する必要があります。

後者のクラスの名前をDroppedItemなどに変更することでこの特定の問題が解決された場合、識別子とは一致しなくなります。

クラスを見つけやすくするために識別子を一致させることが重要であることに同意しますが、完全に一致さDroppedなどの明確な単語を追加しても問題ありません。

「OCDを満たすためにすべての識別子を完全に一致させる」と「使いやすい名前を付ける」の間で、2番目を選択します。

Mojangがアイテムをデータ駆動型にするとすぐにItemTypeになると確信しているので、今のところこれを保留するのが最善です。

Item -> ItemType （およびBlock -> BlockType ）は非常に重要であり、できるだけ早く実行する必要があると思います。 Itemは、すべてのアイテムにクラスのインスタンスがないため、間違っています。 それは、アイテムクラスのフィールドにアイテムの状態を保存するという間違いを犯すために、改造に不慣れな人々にさえつながります。

minecraft:x_typeレジストリに関する識別子および現在の規則と矛盾しています。

その慣習は意味がありません。 レジストリには、個々のアイテムとブロックのインスタンスではなく、アイテムタイプとブロックタイプが格納されます。 _typeサフィックスのバリエーションは、Mojangによる不整合であり、識別子のタイプミスをコピーしないのと同じように、コピーしないでください。

正直なところ、ルーンは、「私はいくつかの牛の実体を殺すために出かける」ということは、技術コミュニティから来て、私にとって自然に聞こえることからそう遠くはありません。

Minecraftを自然言語のように読み上げたい場合は、他にも多くの名前変更を行うことができます。 「いくつかの木の特徴を切り落とすつもりです」は誰にとってもよく読めません。 それは私たちが名前を変更する必要があります意味していますTreeFeatureにTree ？ 番号！ しかし、「牛の実体」は実際にはよく読めます。 特に、「1つの場所に多くの牛のエンティティがあるため、サーバーが遅れている」などのコンテキストでは。

それは私たちが名前を変更する必要があります意味していますTreeFeatureにTree ？

はい、ここでのFeatureという単語はここでは冗長です。 また、機能クラスの最後にGeneratorを追加することをお勧めします。これらは実際には機能自体ではなく、機能のジェネレーターであるためです。 TreeGenerator extends FeatureGeneratorようなものがあります。

一箇所にたくさんの牛の実体があるため、サーバーは遅れています

このように言う理由は、サーバーに遅れをとっているのはたまたま牛であるエンティティであるという事実を強調するためだと思います。

しかし、一般的に、この強調は必要ありません。 コンテンツを追加するだけの通常のmod（パフォーマンス向上modではない）に取り組んでいる場合、「牛タイプのエンティティを生成する」ではなく、「牛をスポーンする」ことを考えているので、書きたいと思います。そのように私のコード。

しかし、彼らは牛ではなく、牛の実体です。 牛の概念は自然言語でのみ存在します。CowEntityは、牛の概念全体ではなく、牛の_エンティティ_を具体的に指します。 そのクラスには、牛の他の部分（ドロップなど）に関連するコードは入れません。

このバイクシェディングは役に立たない...

Entity接尾辞は、「このクラスとは何か」を疑うことがないため、明確です。 Minecraftのコンテキストでは、 Entityは明らかにThingの同義語ではありません。

また、改造者のために、これほど大きな変更を導入しないでください。更新が行われるときに、誰かがEntityサフィックスを嫌っていたために、ワークスペースをクソすることで改造者を難しくする必要がないので、すでに十分に複雑です。

確かに、それを変更して、500エラーのためにmodがコンパイルされないため、全世界が燃えるのを見てください。 確かにmigrateMappingsがありますが、変更のためにそれを実行しなければならないのはなぜですか。

この号は1年間発行されており、適用されませんでした。 その間、人々はEntityサフィックスを使用しました。 個人的には、そのような変更がマージされて、現在のすべてのmodワークスペースが爆発するのを見て非常に腹を立てます。

また、自然言語はかっこいいですが、これはゲームエンジンに固有のものであり、小説のようにコードを読み取ろうとすることは不可能です。

私もノーと言わざるを得ません。 あいまいになる場合がたくさんあります（前述のItemEntity 、およびArrowEntityまたはTridentEntity ）。

私はこのアイデアのファンではありません、私はそれが話された言語でそれがどのように言ったかに本当に要約するとは思わない。 それは糸全体で一貫している必要があり、エンティティからそれを削除することは奇妙に思えます。どこでも（ブロックとアイテム）それを削除することはまったく意味がありません。

投票を見て、それは明らかだと思いますか？

LivingEntity ： LivingまたはEntity ：なし、接尾辞は他の名前との一貫性を提供します、私は@lに同意します- CowEntityルナは牛はCowEntity表し、 Cowはエンティティ、そのドロップ、およびそのモデル/レンダーを表します。 Entity接尾辞は誰にも害を及ぼすものではなく、 BlockEntityも使用されている接尾辞であるという事実に加えて、万が一の場合に備えて説明を追加するのに役立つと思います。 ちょうど私の2セント。

LivingEntity：LivingまたはEntity：と呼びますか

私はLivingEntityを「生きている実体」と呼んでいるので、その名前はそのままにしておく必要があります。 私はCowEntityを「牛」と呼んでいるので、名前を変更する必要があります。

私の問題は、サーバー側のみのように名前を付けようとしていることです。サーバー側のみのAPIでCowEntity Cowという名前を付けることは、文字通り牛の概念全体であるため、意味があります。サーバー。

しかし、ここにはクライアントもあります。牛のプロパティを処理するオブジェクトであるEntityによって牛が定義されるため、 CowEntity Cowという名前は明らかに間違っています。世界とその目標と相互作用します。 モデルとレンダラーによっても！

CowEntity Cowという名前を付けることで、クラスの意味の大部分を取り除き、誤解を招くようにします。

糸がサーバー側だけであれば問題ありませんが、そうではありません。

サーバー上でも、 CowEntityは、データパックに個別に保存された戦利品テーブルもあるため、牛を完全に表すわけではありません。 そして、技術的に話すとき、私はCowEntity代わりにCow CowEntityと言います。 ゲームプレイのチュートリアルではなく、技術的なマッピングセットを作成しています。 はい、通常のゲームプレイではChestBlockEntityをチェストと呼びますが、これは通常のゲームプレイではなく、 ChestBlockを混乱させたくないmod作成です。 ChestBlockEntityとチェストルートテーブル。 はい、たとえばクリーパーの場合はサフィックスが冗長ではないため、たとえばクリーパーの場合はサフィックスを保持する必要があります（ LivingEntity 、 Entity 、 ItemEntity ）、およびIMO文法的に正しいよりも、技術情報に一貫性を持たせる方がよいでしょう。

ほとんどがそれに反対しているので、これを閉じます。