Yarn: Jatuhkan awalan 'Teks' dalam model teks

Dibuat pada 28 Okt 2018  ·  13Komentar  ·  Sumber: FabricMC/yarn

Saat ini net/minecraft/text memiliki semua komponen model teks yang diawali dengan TextComponent , berbeda dengan skema penamaan Mojang sendiri ( XComponent ).

Penting untuk dicatat bahwa hanya TextComponent secara langsung mewakili teks aktual, sisanya hanyalah placeholder selain model yang dibangun ke dalam sisi klien teks. IMO awalan Text bertele-tele dan tidak perlu.

Saya mengusulkan agar kita menggunakan penamaan Mojang (jika diketahui) dan perubahan berikut:

  • net/minecraft/text/ITextComponent -> net/minecraft/text/Component (ini diberikan dalam beberapa kode serialisasi).
discussion

Komentar yang paling membantu

Fabric cenderung menggunakan awalan umum di semua tempat, yang cukup berguna untuk penyelesaian dan pengenalan otomatis IDE. Tidak menggunakan Teks* tidak akan cocok dengan yang lainnya.

Saya lebih suka menjatuhkan infiks "Komponen", secara teknis salah ("komponen" biasanya merujuk semuanya, bukan bagian ("komponen") dari sesuatu) dan tidak menambah keterbacaan.

Semua 13 komentar

Saya mengusulkan bahwa kita harus menggunakan penamaan Mojang (jika diketahui)

Itu selalu menjadi poin yang kontroversial: beberapa pengembang Fabric berpendapat bahwa nama-nama tersebut harus diperbaiki jika berlaku. Saya, secara pribadi, percaya bahwa sementara nama resmi adalah petunjuk yang berguna, kita harus memperlakukan mereka hanya sebagai - petunjuk. Selain itu, saya tidak percaya nama di toString selalu mencerminkan nama kelas yang sebenarnya.

Bagaimanapun, saya menentang, tapi saya penggemar verbositas.

  • "Komponen" adalah kata kunci umum yang dapat dengan mudah dibayangkan terjadi di banyak pola konten yang dimodifikasi, bahkan berpotensi tidak jauh dari kode pengirim pesan obrolan.
  • Menggunakan atau tidak menggunakan "I" untuk menandai antarmuka, sekali lagi, merupakan titik perdebatan - meskipun saya pikir kami umumnya memutuskan untuk menggunakannya, mungkin dengan pengecualian turunan langsung dari antarmuka Java (katakanlah, IntIterable memperluas Iterable).

Fabric cenderung menggunakan awalan umum di semua tempat, yang cukup berguna untuk penyelesaian dan pengenalan otomatis IDE. Tidak menggunakan Teks* tidak akan cocok dengan yang lainnya.

Saya lebih suka menjatuhkan infiks "Komponen", secara teknis salah ("komponen" biasanya merujuk semuanya, bukan bagian ("komponen") dari sesuatu) dan tidak menambah keterbacaan.

"Komponen" adalah kata kunci umum yang dapat dengan mudah dibayangkan terjadi di banyak pola konten yang dimodifikasi, bahkan berpotensi tidak jauh dari kode pengirim pesan obrolan.

Itu poin yang adil, meskipun saya tidak berpikir itu akan membuat perbedaan yang terlalu besar (jarang diimpor) - subclass (Teks, Skor, dll) Saya benar-benar ragu dapat memisahkan sistem lain jadi saya tidak berpikir itu begitu banyak masalah.

Menggunakan atau tidak menggunakan "I" untuk menandai antarmuka, sekali lagi, merupakan titik perdebatan - meskipun saya pikir kami umumnya memutuskan untuk menggunakannya, mungkin dengan pengecualian turunan langsung dari antarmuka Java (katakanlah, IntIterable memperluas Iterable).

Nah itu diskusi yang berbeda, saya memiliki preferensi saya tetapi itu dapat didiskusikan di tempat lain - untuk tujuan diskusi ini saya akan senang dengan Component atau IComponent .


Fabric cenderung menggunakan awalan umum di semua tempat, yang cukup berguna untuk penyelesaian dan pengenalan otomatis IDE. Tidak menggunakan Teks* tidak akan cocok dengan yang lainnya.

Betulkah? Anda pasti masih mendapatkan penyelesaian untuk TextComponent , dan saya akan membayangkan yang lain juga (mengingat paketnya, tapi saya rasa itu tergantung pada IDE).

Saya lebih suka menjatuhkan infiks "Komponen", secara teknis salah ("komponen" biasanya merujuk semuanya, bukan bagian ("komponen") dari sesuatu) dan tidak menambah keterbacaan.

Hanya karena dalam banyak kasus hanya satu komponen yang digunakan, tidak mengurangi bahwa banyak yang dapat digunakan (dan seringkali - misalnya Press <x> button to jump ). Komponen adalah bagian penting dari nama.

Hal ini, sementara ini tentu saja terpisah dari model teks (karenanya net/minecraft/text ) hanya satu komponen ( TextComponent ) adalah teks yang sebenarnya - sisanya adalah pengganti untuk diisi oleh klien. IMO tidak masuk akal untuk mengulang paket untuk komponen dalam nama kelas.

Mereka semua mewakili teks yang dapat dilokalkan, biasanya untuk ditampilkan pada klien. "Teks" menyampaikan secara alami bahwa itu dapat disematkan ke dalam dirinya sendiri.

Jika Anda memikirkannya dari arah lain, "komponen" tidak memiliki wadah nyata, selalu dibatasi untuk dirinya sendiri sampai dikonsumsi atau diekspor ke string. "Komponen" adalah pembedaan yang tidak perlu terhadap sesuatu yang tidak ada. Pengupasan "Teks" membuatnya sama generik dan tidak berarti seperti "Elemen", "Bagian" atau serupa, kehilangan deskripsi identitas/tujuannya.

Tentang argumen paket: Saya yakin Anda tidak benar-benar melihat nama paket saat membaca kode...

Tentang argumen paket: Saya yakin Anda tidak benar-benar melihat nama paket saat membaca kode...

Tentu, ketika membaca konteks kode adalah di mana Anda akan tahu teksnya terkait - paket hanya benar-benar relevan saat mengimpor. Meskipun mengimpor adalah satu-satunya kasus, saya melihatnya sebagai masalah ...

// Even when using Component in a field, context easily allows you to
// know its text-related
final Component message = new TextComponent("Hello, World!");
player.message(message);

// Each of the components are fairly easily identifiable as text
player.message(new KeybindComponent("key.jump"));
player.message(new TranslatableComponent("info.kick", "player-x"));
player.message(new ScoreComponent("name", "objective"));
player.message(new SelectorComponent("pattern"));

Lihatlah contoh untuk kyori/text , untuk melihat bahwa bahkan tanpa awalan 'Teks' masih sangat mudah untuk melihat apa artinya dan terlihat lebih bersih juga (IMO ofc).

Anda mungkin ada benarnya dengan contoh kode, meskipun saya masih berpendapat bahwa ScoreComponent/SelectorComponent/KeybindComponent dapat membingungkan dalam konteks tertentu.

Dan saya masih tidak begitu yakin untuk memanggil basis "Komponen". Menggosok saya dengan cara yang salah.

Dan saya masih tidak begitu yakin untuk memanggil basis "Komponen". Menggosok saya dengan cara yang salah.

Mungkin, tapi itu tidak biasa - ambil org.w3.dom.Node misalnya.

Saya tidak akan menghapus awalan Teks karena Komponen saja akan menyebabkan kebingungan karena ada banyak kelas serupa dengan nama yang sama

Oke tapi mari kita lihat apa yang terjadi sebaliknya:

// Even without Component in the name, names are still focused on the object's use
// Note that I've reversed from StringText to TextString because it flows more naturally
// in english
final Text message = new TextString("Hello, World!");
player.message(message);

// Each of these objects' purposes are easily determined without the word "Component"
player.message(new KeybindText("key.jump"));
player.message(new TranslatableText("info.kick", "player-x"));
player.message(new ScoreText("name", "objective"));
player.message(new SelectorText("pattern"));

Sepertinya sah bagi saya.

Yah, seperti yang kashike ingatkan saya - Mojang tidak menyebutnya komponen teks - mereka menyebutnya komponen obrolan (Anda hanya perlu melihat log perubahan untuk mengetahui hal ini).

Mereka juga tidak merujuk ke komponen teks sebagai komponen teks string - teks untuk mereka, adalah apa yang disebut fabric string.

Namun mojang konfirmasi lain menyebut mereka komponen
image

Penelitian saya mengarahkan saya bahwa ada dalam paket obrolan di jaringan untuk apa nilainya -> https://github.com/jamiemansfield/mcmap/tree/18w50a/workspace/net/minecraft/network/chat

(Sunting: Ponsel konyol)

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

Sollace picture Sollace  ·  5Komentar

ChloeDawn picture ChloeDawn  ·  6Komentar

asiekierka picture asiekierka  ·  3Komentar

quat1024 picture quat1024  ·  3Komentar

Runemoro picture Runemoro  ·  4Komentar