Yarn: Jatuhkan akhiran 'Entitas'

Dibuat pada 16 Jan 2019  ·  44Komentar  ·  Sumber: FabricMC/yarn

  • Tidak ada ambiguitas di hampir semua kasus
  • Itu akan membuat kode kurang bertele-tele
  • Kami tidak mengatakan "lima entitas sapi", melainkan "lima sapi" (tetapi kami mengatakan "lima balok batu" daripada "lima batu", itulah sebabnya mereka harus mempertahankan akhiran Blok)
  • Mojang tidak menggunakan sufiks Entity
discussion vote

Komentar yang paling membantu

Jika Anda mengatakan "Saya punya 5 batu" tolong :+1: masalah ini

Semua 44 komentar

Ini hanya menjatuhkan Entity untuk entitas biasa dan bukan BlockEntities, ya?

Ya.

Sponge juga tidak menggunakan sufiks Entity .

+1 tetapi tidak bisakah argumen itu juga digunakan untuk hal-hal seperti blok? Hampir tidak pernah bentrok. Saya suka ide blok. Dada tetapi jika Anda membuat sesuatu yang tidak benar-benar terkait dengan blok, itu akan menjadi aneh.

Saya tidak setuju demi konsistensi

Hal dengan akhiran Block , IMO, adalah bahwa itu menunjukkan bukan hanya sebuah blok, tetapi juga blok. Ambil rumput misalnya, ada hanya pernah satu contoh dari GrassBlock pada waktu tertentu, sehingga aman untuk mengatakan "ini adalah grass block". Entitas tidak benar-benar berfungsi seperti ini, karena ada instance entitas untuk masing-masing entitas di dunia. Jadi, sebagai contoh lain, dengan zombie, Anda tidak dapat mengatakan "ini adalah zombie", karena ada beberapa zombie, bukan hanya satu. Anda akan mengatakan "ini adalah zombie".

Di sisi lain, argumen konsistensi membuat kasus yang bagus - agak tidak konsisten jika kita menambahkan beberapa hal dengan tipenya dan membiarkan yang lain tanpa akhiran.

hmm, bagaimana dengan balok jatuh?

@Sorixelle membuat

jadi ZombieEntity berarti tipe Entitas untuk zombie?

tidak bisakah argumen itu juga digunakan untuk hal-hal seperti balok?

Saya tidak setuju demi konsistensi

Perbedaannya adalah kita mengatakan "Saya punya 5 balok batu" (bukan "5 batu"), tetapi "Saya punya 5 domba" (bukan "entitas domba").

Jika Anda mengatakan "Saya punya 5 batu" tolong :+1: masalah ini

Bayangkan jika kita menamai kelasnya SheepThing dan ItemThing .

Itulah tepatnya yang kita miliki, karena "entitas" hanyalah sinonim untuk "benda" dan "objek" .

Entitas mencakup semua objek dinamis dan bergerak di seluruh dunia Minecraft.

Apakah Anda setuju dengan nama SheepDynamicObject atau SheepGameObject ?

"artikel", "objek" dan "benda" adalah sinonim dari "barang" . Haruskah kita mengganti nama SwordItem menjadi SwordArticle , SwordObject atau SwordThing ?

Intinya adalah bahwa SheepThing dan ItemThing adalah variasi yang tidak berarti ketika konsep "entitas" didefinisikan dengan baik sebagai sesuatu yang lebih spesifik daripada "benda" atau "objek" di Minecraft, seperti "barang".

Saya tidak mengatakan bahwa Entitas tidak ada artinya. Saya mengatakan bahwa ini adalah istilah umum yang digunakan untuk semua hal dinamis, dengan cara yang sama kita memiliki java.lang.Object , tetapi tidak StringObject , IntegerObject , dll.

Poin yang saya coba buat dengan perbandingan itu adalah bahwa jika Mojang telah menamai Entity Thing sebagai gantinya, apakah Anda akan tetap memiliki SheepThing , ItemThing ?

"artikel", "objek" dan "benda" adalah sinonim dari "barang" . Haruskah kita mengganti nama SwordItem menjadi SwordArticle , SwordObject atau SwordThing ?

Intinya adalah bahwa SheepThing dan ItemThing adalah variasi yang tidak berarti ketika konsep "entitas" didefinisikan dengan baik sebagai sesuatu yang lebih spesifik daripada "benda" atau "objek" di Minecraft, seperti "barang".

Saya tidak melihat alasan untuk membuatnya lebih kompleks dengan nama item menjadi artikel atau benda.

Shulkers adalah contoh bagus di mana menghapus denotasi entitas dapat membuat hal-hal membingungkan karena skenario penamaan yang serupa dan entitas blok, blok, dan definisi entitas dengan nama yang sama.

Saya tidak mengatakan bahwa Entitas tidak ada artinya. Saya mengatakan bahwa ini adalah istilah umum yang digunakan untuk semua hal dinamis, dengan cara yang sama kita memiliki java.lang.Object , tetapi tidak StringObject , IntegerObject , dll.

java.lang.Object adalah superclass dari setiap kelas, dan kelas entitas membuat sebagian kecil dari itu.

bagaimana Anda memisahkan Item dari ItemEntity, misalnya.
Juga, standar Java menunjukkan EnumSet, EnumMap dll, jadi kelas dasar adalah bagian dari ekstender
CompoundTag, ListTag, StringTag...

Menambahkan tipe super adalah praktik umum

Drop untuk entitas untuk ItemType untuk elemen registri

Registri minecraft:item adalah Registry dari Item , bukan ItemType , dan ID tipe entitas adalah minecraft:item jadi ItemEntity .

Tentu, mempertahankan sufiks Entity bukanlah masalah besar. Kita bisa hidup dengan itu.

Ya, tolong jangan lepaskan akhiran Entity. Itu hanya akan menyebabkan kebingungan, dan alih-alih menamai sesuatu secara akurat, kami hanya akan mencoba memberi nama hal-hal agar tidak dikacaukan dengan entitas tanpa akhiran

Poin yang saya coba buat dengan perbandingan itu adalah bahwa jika Mojang telah menamai Entity Thing sebagai gantinya, apakah Anda akan tetap memiliki SheepThing , ItemThing ?

Ya, karena Thing akan memiliki arti khusus dalam kasus itu.

Seperti kata Yanis, menghilangkan sufiks hanya akan menimbulkan kebingungan. Nama adalah untuk kejelasan, bukan "terlihat bagus".

Nama adalah untuk kejelasan, bukan "terlihat bagus".

Nama yang terdengar alami sama pentingnya dengan kejelasan.

Bayangkan saya berkata saat bermain Minecraft "Saya akan membunuh beberapa entitas sapi untuk mendapatkan beberapa item daging sapi mentah dan kemudian menggunakan blok tungku untuk mengubahnya menjadi item daging sapi yang dimasak".

Pencocokan kode dengan cara kita berpikir dan berbicara adalah hal yang sangat baik.

Anda dapat memiliki keduanya secara bersamaan: dasar alami (sapi, daging sapi mentah, tungku), dan sufiks klarifikasi (entitas, item, blok).

Intinya adalah bahwa sufiks tidak diperlukan. Kita tahu sapi adalah entitas dan daging sapi adalah item. Tidak ada yang mengatakan "entitas sapi" atau "daging sapi", jadi mengapa kita harus mengatakan/membacanya saat menulis/membaca kode?

masih ada masalah ItemEntity .

Ya Item adalah satu-satunya alasan saya tidak melihat ini berfungsi. Saya mungkin tidak akan menyetujuinya kecuali jika kita melakukan Item -> ItemType tapi itu adalah perubahan nama yang lebih besar karena banyaknya item dalam game.

Pilihan lainnya adalah mengklarifikasi ketika nama menjadi ambigu tetapi menyebabkan nama menjadi tidak konsisten.

ItemEntity -> DroppedItem , mirip dengan cara kita memiliki ThrownSnowballEntity

Kita tahu sapi adalah entitas dan daging sapi adalah item. Tidak ada yang mengatakan "entitas sapi" atau "daging sapi", jadi mengapa kita harus mengatakan/membacanya saat menulis/membaca kode?

Satu-satunya pilihan lain adalah menjadi tidak konsisten tidak peduli solusinya.

Menjatuhkan sufiks akan menyebabkan masalah dengan kelas untuk konten dari registri yang berbeda. Kelas dasar Item secara definitif dinamai demikian karena ada registri yang penuh dengannya (atau subkelasnya) menggunakan pengenal minecraft:item . Demikian juga, kelas entitas ItemEntity secara definitif dinamai demikian karena masing-masing tipe entitas terdaftar di registri minecraft:entity_type sebagai minecraft:item . Kelas Item akan tetap sebagai Item , tetapi kelas ItemEntity juga akan menjadi Item .

Jika masalah khusus ini diselesaikan dengan mengubah nama kelas terakhir menjadi DroppedItem atau serupa, maka itu tidak akan lagi cocok dengan pengenal. Ini adalah masalah karena ada kepercayaan yang cukup bahwa pengidentifikasi menjadi representasi yang baik untuk nama kelas bahwa kami memiliki sistem penamaan bidang otomatis saat ini di kelas konten registri, dan menambahkan akhiran registri ke nama kelas.

Seluruh gagasan untuk menghilangkan sufiks juga tidak konsisten dengan standar Java (lihat implementasi Daftar atau Peta), seperti yang disebutkan sebelumnya .

Saya mungkin tidak akan menyetujuinya kecuali jika kita melakukan Item -> ItemType tapi itu adalah perubahan nama yang lebih besar karena jumlah item yang digeser dalam game.

Saya yakin akan ada ItemType segera setelah Mojang membuat item berdasarkan data, jadi sebaiknya tunda dulu untuk saat ini. Selain itu, ini masih tidak konsisten dengan pengidentifikasi dan konvensi kami saat ini mengenai registri minecraft:x_type .

ItemEntity -> DroppedItem , mirip dengan cara kita memiliki ThrownSnowballEntity

Sekali lagi, ini tidak sesuai dengan standar Java dan standar Benang. Saya ingin tahu tentang diskusi apa pun tentang ThrownSnowballEntity meskipun mengingat pengenalnya adalah minecraft:snowball .

Seluruh gagasan untuk menghilangkan sufiks juga tidak konsisten dengan standar Java (lihat implementasi Daftar atau Peta),

HashMap bukan hash, melainkan peta hash[-based], dan ArrayList bukan array, melainkan daftar array[-based]. CowEntity adalah seekor sapi. Ini seperti mengatakan kita harus mengatakan "hewan sapi" daripada "sapi" karena kita mengatakan "rautan pensil" daripada "pensil"...

Lihat Java AWT. Semuanya meluas Component , tetapi kita hanya memiliki Button daripada ButtonComponent , Scrollbar daripada ScrollbarComponent , dll. Jadi jika kita mengikuti Standar Java, kita harus menyingkirkan sufiks.

Jika masalah khusus ini diselesaikan dengan mengubah nama kelas terakhir menjadi DroppedItem atau serupa, maka itu tidak akan lagi cocok dengan pengenal.

Saya setuju bahwa mencocokkan pengidentifikasi penting untuk membuat kelas mudah ditemukan, tetapi saya tidak mengerti mengapa kita harus mencocokkannya sepenuhnya . Menambahkan beberapa kata klarifikasi seperti Dropped tidak masalah.

Antara "cocok dengan semua pengidentifikasi dengan sempurna untuk memuaskan OCD saya" dan "memiliki nama yang bagus untuk digunakan", saya akan memilih yang kedua.

Saya yakin akan ada ItemType segera setelah Mojang membuat item berdasarkan data, jadi sebaiknya tunda dulu untuk saat ini

Saya pikir Item -> ItemType (serta Block -> BlockType ) sangat penting dan harus dilakukan sesegera mungkin. Item hanya salah, karena tidak ada turunan dari kelas untuk setiap item. Bahkan membuat orang yang baru mengenal modding membuat kesalahan dengan menyimpan status item di bidang di kelas item.

tidak konsisten dengan pengenal dan konvensi kami saat ini mengenai registri minecraft:x_type .

Konvensi itu tidak masuk akal. Pendaftar menyimpan tipe item dan tipe blok, bukan instance dari setiap item dan blok individual. Variasi pada sufiks _type adalah inkonsistensi oleh Mojang, dan kita tidak boleh menyalinnya, sama seperti kita tidak akan menyalin kesalahan ketik pada pengenal.

Sejujurnya Rune, "Saya akan keluar untuk membunuh beberapa entitas sapi" tidak jauh dari terdengar alami bagi saya, berasal dari komunitas teknologi.

Jika Anda ingin membuat Minecraft dibaca seperti bahasa alami, ada banyak penggantian nama lain yang dapat Anda lakukan. "Saya akan menebang beberapa fitur pohon" tidak dibaca dengan baik untuk siapa pun. Apakah itu berarti kita harus mengganti nama TreeFeature menjadi Tree ? Tidak! Tapi "entitas sapi" sebenarnya terbaca dengan baik. Terutama dalam konteks seperti "server tertinggal karena ada banyak entitas sapi di satu tempat".

Apakah itu berarti kita harus mengganti nama TreeFeature menjadi Tree ?

Ya, kata Feature sini berlebihan di sini. Saya juga menyarankan untuk menambahkan Generator di akhir kelas fitur, karena mereka sebenarnya adalah generator untuk fitur, bukan fitur itu sendiri. Kami akan memiliki sesuatu seperti TreeGenerator extends FeatureGenerator .

servernya lag karena ada banyak entitas sapi di satu tempat

Saya menduga alasan Anda mengatakannya seperti ini adalah untuk menekankan fakta bahwa entitasnya, yang kebetulan adalah sapi, yang tertinggal di server.

Tetapi secara umum penekanan ini tidak diperlukan. Jika saya sedang mengerjakan mod biasa yang hanya menambahkan konten (bukan mod peningkatan kinerja), saya akan berpikir tentang "membiakkan beberapa sapi", bukan "menelurkan entitas tipe sapi", dan saya ingin menulis kode saya seperti itu.

Tapi mereka _adalah_ Entitas Sapi, bukan Sapi. Ide tentang sapi hanya ada dalam bahasa alami - CowEntity secara khusus mengacu pada _entitas_ sapi, bukan keseluruhan konsep sapi. Anda tidak akan meletakkan kode yang berhubungan dengan bagian lain dari sapi - seperti tetesannya - di kelas itu.

Perpisahan sepeda ini tidak berguna...

Sufiks Entity jelas karena tidak membuat Anda ragu "apa kelas ini?". Dalam konteks Minecraft Entity jelas bukan sinonim dari Thing .

Juga demi para modder, jangan membuat perubahan besar sebesar ini, itu sudah cukup rumit ketika pembaruan datang, Anda tidak perlu mempersulit para modder dengan mengacaukan ruang kerja mereka karena seseorang tidak menyukai akhiran Entity .

Seperti yakin, silakan ubah, dan saksikan seluruh dunia terbakar karena sekarang mod tidak dapat dikompilasi karena 500 kesalahan. Tentu ada migrasiMappings tetapi mengapa saya harus menjalankannya untuk perubahan yang begitu tidak berarti .

Masalah ini telah dibuka selama 1 tahun, dan tidak diterapkan. Dan sementara itu orang menggunakan akhiran Entity . Secara pribadi saya akan sangat kesal melihat perubahan seperti itu digabungkan sehingga meledakkan semua ruang kerja mod saya saat ini.

Juga, ok bahasa alami itu keren dan semuanya, tapi ini khusus untuk mesin permainan, mencoba membaca kode seperti novel tidak mungkin.

Saya juga harus mengatakan tidak. Ada banyak kasus ketika itu akan menjadi ambigu (yang disebutkan di atas ItemEntity , serta ArrowEntity atau TridentEntity ).

Saya bukan penggemar ide ini, saya tidak berpikir itu benar-benar bermuara pada bagaimana dikatakan dalam bahasa lisan. Itu harus konsisten di seluruh benang, dan menghapusnya dari entitas yang adil tampaknya aneh, menghapusnya di mana-mana (blok dan item) tidak masuk akal sama sekali.

Melihat suara, tebak sudah jelas?

Apakah Anda memanggil LivingEntity : Living atau Entity : tidak ada, sufiks memberikan konsistensi dengan nama lain, saya setuju @l-Luna dengan CowEntity tidak mewakili a Cow itu mewakili CowEntity , a Cow mewakili entitas, drop-nya, dan model/render-er-nya. Sufiks Entity tidak merugikan siapa pun, dan saya pikir mereka membantu menambahkan beberapa klarifikasi untuk berjaga-jaga, bersama dengan fakta bahwa BlockEntity adalah sufiks yang digunakan juga. Hanya 2 sen saya.

Apakah Anda memanggil LivingEntity: Living atau Entity:

Saya menyebut LivingEntity sebagai "entitas hidup", jadi nama itu harus tetap ada. Saya menyebut CowEntity sebagai "sapi", jadi nama itu harus diubah.

Masalah saya adalah Anda mencoba menamai hal-hal seperti itu hanya sisi server, tentu saja menamai CowEntity Cow pada API sisi server saja akan masuk akal karena secara harfiah seluruh konsep sapi untuk sebuah server.

Tapi di sini ada juga klien, penamaan CowEntity Cow jelas salah karena sapi didefinisikan oleh Entity yang merupakan objek yang menangani properti sapi, bagaimana berinteraksi dengan dunia dan tujuannya; tetapi juga oleh model dan penyajinya!

Dengan memberi nama CowEntity Cow Anda menghapus sebagian besar makna kelas dan membuatnya menyesatkan.

Saya akan baik-baik saja dengan ini jika benang hanya sisi server, tetapi tidak.

Bahkan di server CowEntity tidak sepenuhnya mewakili seekor sapi karena ia juga memiliki tabel jarahan yang disimpan secara terpisah dalam paket data. Dan ketika berbicara secara teknis saya mengatakan CowEntity bukannya Cow . Kami tidak membuat tutorial gameplay, kami membuat set pemetaan teknis. Ya, Anda akan menyebut ChestBlockEntity peti dalam permainan normal, tetapi ini bukan permainan normal, ini adalah pembuatan mod, di mana Anda tidak ingin membingungkan ChestBlock , ChestBlockEntity dan meja jarahan peti. Ya, Anda harus menyimpan sufiks meskipun itu berlebihan untuk mengatakan creepers, karena untuk hal-hal lain sufiks tidak berlebihan ( LivingEntity , Entity , ItemEntity ), dan IMO lebih baik konsisten dalam informasi teknis daripada benar secara tata bahasa.

Menutup ini karena sebagian besar menentangnya.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

haykam821 picture haykam821  ·  4Komentar

Boundarybreaker picture Boundarybreaker  ·  3Komentar

liach picture liach  ·  4Komentar

Bixilon picture Bixilon  ·  5Komentar

Awakened-Redstone picture Awakened-Redstone  ·  4Komentar