Yarn: قم بإسقاط لاحقات "الكيان"

هذا مجرد إسقاط Entity للكيانات العادية وليس BlockEntities ، أليس كذلك؟

بلى.

لا يستخدم Sponge أيضًا اللواحق Entity .

+1 ولكن ألا يمكن استخدام هذه الحجة أيضًا لأشياء مثل الكتل؟ يكاد لا يصطدم أبدًا. أنا أحب فكرة الكتل. صندوق ولكن إذا كنت تصنع شيئًا لا يرتبط بالحظر تمامًا ، فسيكون ذلك غريبًا.

أنا لا أوافق من أجل الاتساق

الشيء الذي يحتوي على اللاحقة IMO Block هو أنه لا يشير فقط إلى كتلة ، بل إلى الكتلة. خذ العشب على سبيل المثال، لا يوجد سوى واحد من أي وقت مضى مثيل GrassBlock في أي وقت من الأوقات، لذلك فمن الأسلم أن نقول "هذا هو كتلة العشب". لا تعمل الكيانات بهذه الطريقة حقًا ، لأن هناك مثيلًا للكيان لكل واحد في العالم. وهكذا، كمثال آخر، مع الكسالى، لا يمكنك القول "هذا هو غيبوبة"، لأن هناك الكسالى متعددة، وليس واحدة فقط. وكنت أقول "هذا هو غيبوبة".

من ناحية أخرى ، فإن حجة التناسق تقدم حالة جيدة - إنها غير متسقة بعض الشيء إذا قمنا بملحق بعض الأشياء بنوعها وترك الآخرين بدون لاحقات.

حسنًا ، ماذا عن الكتلة المتساقطة؟

Sorixelle يشير إلى نقطة جيدة حقًا. لكني أعتقد أننا يجب أن نجد سببًا للاحقة ، نعم من الرائع عدم ذكر الاسم ، لكن ليس متسقًا.

إذن ZombieEntity تعني نوع الكيان للزومبي؟

ألا يمكن استخدام هذه الحجة أيضًا لأشياء مثل الكتل؟

أنا لا أوافق من أجل الاتساق

الفرق هو أننا نقول "لدي 5 كتل حجرية" (وليس "5 أحجار") ، ولكن "لدي 5 خراف" (وليس "كيانات خراف").

إذا قلت "لدي 5 أحجار" من فضلك: +1: هذه المسألة

تخيل لو قمنا بتسمية الفئات SheepThing و ItemThing .

هذا بالضبط ما لدينا ، لأن "الكيان" هو مجرد مرادف لكلمة "شيء" و "كائن" .

هل "الكيان" مرادف لكلمة "شيء" و "كائن"؟ نعم.

هل هذا يعني أن الكيان لا يمكن أن يكون شيئًا أكثر تحديدًا في Minecraft؟

تشمل الكيانات جميع الكائنات الديناميكية والمتحركة في جميع أنحاء عالم Minecraft.

هل ستوافق على الأسماء SheepDynamicObject أو SheepGameObject إذن؟

"المقالة" و "الكائن" و "الشيء" مرادفات لكلمة "عنصر" . هل يجب إعادة تسمية SwordItem إلى SwordArticle أو SwordObject أو SwordThing ؟

النقطة المهمة هي أن SheepThing و ItemThing عبارة عن اختلافات لا معنى لها عندما يتم تعريف مفهوم "الكيان" جيدًا على أنه شيء أكثر تحديدًا من "شيء" أو "كائن" في Minecraft ، تمامًا مثل "العنصر".

أنا لا أقول أن الكيان لا معنى له. أنا أقول إنه مصطلح عام يُستخدم لجميع الأشياء الديناميكية ، بنفس الطريقة التي نستخدم بها java.lang.Object ، لكن ليس StringObject ، IntegerObject ، إلخ.

النقطة التي كنت أحاول توضيحها من خلال هذه المقارنة هي أنه إذا كان Mojang قد أطلق على Entity Thing بدلاً من ذلك ، فهل ستستمر في الحصول على SheepThing ، ItemThing ؟

"المقالة" و "الكائن" و "الشيء" مرادفات لكلمة "عنصر" . هل يجب إعادة تسمية SwordItem إلى SwordArticle أو SwordObject أو SwordThing ؟

النقطة المهمة هي أن SheepThing و ItemThing عبارة عن اختلافات لا معنى لها عندما يتم تعريف مفهوم "الكيان" جيدًا على أنه شيء أكثر تحديدًا من "شيء" أو "كائن" في Minecraft ، تمامًا مثل "العنصر".

لا أرى سببًا لجعل الأمر أكثر تعقيدًا مع إدراج أسماء العناصر في المقالة أو الشيء.

تعد Shulkers أمثلة رائعة على المكان الذي يمكن أن تؤدي فيه إزالة دلالة الكيان إلى إرباك الأشياء بسبب سيناريو تسمية مشابه وكيان كتلة وتعريف وكيان بالاسم نفسه.

أنا لا أقول أن الكيان لا معنى له. أنا أقول إنه مصطلح عام يُستخدم لجميع الأشياء الديناميكية ، بنفس الطريقة التي نستخدم بها java.lang.Object ، لكن ليس StringObject ، IntegerObject ، إلخ.

java.lang.Object هي فئة فائقة من كل فئة ، وتشكل فئات الكيانات جزءًا صغيرًا منها.

كيف يمكنك فصل العنصر عن ItemEntity ، على سبيل المثال.
أيضًا ، يعرض معيار Java EnumSet و EnumMap وما إلى ذلك ، لذا فإن الفئة الأساسية هي جزء من الموسعات
CompoundTag ، ListTag ، StringTag ...

تعد إضافة النوع الفائق ممارسة شائعة

Drop للكيان ItemType لعنصر التسجيل

سجل minecraft:item هو Registry من Item ، وليس ItemType ، ومعرف نوع الكيان هو minecraft:item لذا فهو ItemEntity .

بالتأكيد ، الاحتفاظ باللاحقة 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 أيضًا (انظر تطبيقات القائمة أو الخريطة) ، كما ذكرنا سابقًا .

ربما لن أوافق على ذلك ما لم نقم بـ Item -> ItemType لكن هذه إعادة تسمية أكبر بسبب كمية القص من العناصر في اللعبة.

أنا متأكد من أنه سيكون هناك ItemType بمجرد أن يجعل Mojang العناصر تعتمد على البيانات ، لذلك من الأفضل تأجيل هذا في الوقت الحالي. بالإضافة إلى ذلك ، قد يظل هذا غير متوافق مع المعرف واتفاقياتنا الحالية فيما يتعلق بالسجلات minecraft:x_type .

ItemEntity -> DroppedItem ، على غرار الطريقة التي لدينا ThrownSnowballEntity

مرة أخرى ، سيكون هذا غير متوافق مع معايير Java ومعايير الغزل. أشعر بالفضول حيال أي مناقشة بخصوص ThrownSnowballEntity الرغم من اعتبار أن المعرف الخاص به هو minecraft:snowball .

الفكرة الكاملة لإسقاط اللواحق غير متوافقة مع معيار Java أيضًا (انظر تطبيقات القائمة أو الخريطة) ،

إن A HashMap ليس تجزئة ، بل هو خريطة تجزئة [قائمة على] ، و ArrayList ليست مصفوفة ، بل قائمة [-مستندة إلى]. A CowEntity بقرة. إنه يشبه إلى حد ما قول "حيوان بقرة" بدلاً من "بقرة" لأننا نقول "مبراة" بدلاً من "قلم رصاص" ...

انظر إلى Java AWT. يمتد كل شيء إلى Component ، لكن لدينا فقط Button بدلاً من ButtonComponent ، Scrollbar بدلاً من ScrollbarComponent ، إلخ. لذا إذا اتبعنا معيار جافا ، يجب أن نتخلص من اللواحق.

إذا تم حل هذه المشكلة المحددة عن طريق تغيير اسم الفئة الأخيرة إلى DroppedItem أو ما شابه ذلك ، فلن تتطابق مع المعرف.

أوافق على أن مطابقة المعرفات أمر مهم لتسهيل العثور على الفصول الدراسية ، لكنني لا أفهم لماذا يتعين علينا مطابقتها تمامًا . إضافة بعض الكلمات التوضيحية مثل Dropped أمر جيد.

بين "مطابقة جميع المعرفات بشكل مثالي لإرضاء الوسواس القهري لدي" و "لها أسماء لطيفة في الاستخدام" ، سأختار الثاني.

أنا متأكد من أنه سيكون هناك ItemType بمجرد أن يجعل Mojang العناصر تعتمد على البيانات ، لذلك من الأفضل تأجيل هذا في الوقت الحالي

أعتقد أن 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 ولكن لماذا يجب علي تشغيله من أجل تغيير لا معنى له .

تم فتح هذا الإصدار لمدة عام واحد ، ولم يتم تطبيقه. وفي غضون ذلك ، استخدم الأشخاص اللاحقة Entity . أنا شخصياً سأكون غاضبًا جدًا لرؤية مثل هذا التغيير يتم دمجه وبالتالي تفجير جميع مساحات العمل الحالية الخاصة بي.

أيضًا ، حسنًا ، اللغة الطبيعية رائعة وكل شيء ، لكن هذا خاص بمحرك اللعبة ، ومحاولة قراءة الكود مثل الرواية أمر غير ممكن.

سأضطر إلى قول لا أيضًا. هناك الكثير من الحالات التي يكون فيها الأمر غامضًا ( ItemEntity المذكور أعلاه ، بالإضافة إلى ArrowEntity أو TridentEntity ).

لست من المعجبين بهذه الفكرة ، لا أعتقد أنها تتلخص في كيفية قولها في اللغة المنطوقة. يجب أن يكون متسقًا عبر الغزل ، وإزالته من الكيانات فقط يبدو غريبًا ، وإزالته في كل مكان (الكتل والعناصر) لا معنى له على الإطلاق.

بالنظر إلى التصويت ، تخمين أنه واضح؟

هل تتصل بـ LivingEntity : Living أو Entity : لا شيء ، اللاحقة توفر التناسق مع الأسماء الأخرى ، أوافق @ l-Luna مع CowEntity لا يمثل تمثل البقرة CowEntity ، و Cow تمثل الكيان ، وقطراته ، ونموذج / عرضه. لا تؤذي اللواحق Entity أي شخص ، وأعتقد أنها تساعد في إضافة بعض التوضيح فقط في حالة ، إلى جانب حقيقة أن BlockEntity هي لاحقة مستخدمة أيضًا. فقط سنتان.

هل تسمي LivingEntity: Living أو Entity:

أطلق على LivingEntity "كيانًا حيًا" ، لذلك يجب أن يبقى هذا الاسم. أطلق على CowEntity a "بقرة" ، لذا يجب تغيير هذا الاسم.

مشكلتي هي أنك تحاول تسمية أشياء كما لو كانت من جانب الخادم فقط ، تأكد من تسمية CowEntity Cow على واجهة برمجة تطبيقات من جانب الخادم فقط سيكون منطقيًا لأنه حرفيًا مفهوم البقرة بالكامل الخادم.

ولكن يوجد هنا أيضًا العميل ، تسمية CowEntity Cow خطأ واضح حيث يتم تعريف البقرة من خلال Entity وهو الكائن الذي يتعامل مع خصائص البقرة ، كيف ذلك يتفاعل مع العالم وأهدافه ؛ ولكن أيضًا بنموذجها وعارضها!

بتسمية CowEntity Cow أنت تجرد جزءًا كبيرًا من معنى الفصل وتجعله مضللًا.

سأكون على ما يرام مع هذا إذا كان الغزل من جانب الخادم فقط ، لكنه ليس كذلك.

حتى على الخادم CowEntity لا يمثل بقرة بشكل كامل حيث أنه يحتوي أيضًا على جداول نهب مخزنة بشكل منفصل في حزمة البيانات. وعندما أتحدث تقنيًا أقول CowEntity بدلاً من Cow . نحن لا نصنع درسًا تعليميًا عن طريقة اللعب ، بل نقوم بإعداد مجموعة تعيينات فنية. نعم ، يمكنك الاتصال بـ ChestBlockEntity a صندوق في اللعب العادي ، لكن هذا ليس لعبة عادية ، هذا هو صنع التعديل ، حيث لا تريد الخلط بين ChestBlock ، ChestBlockEntity وطاولة نهب الصدر. نعم ، يجب عليك الاحتفاظ باللاحقة حتى لو كانت زائدة عن الحاجة إلى الزواحف مثلاً ، لأن اللاحقة ليست زائدة عن الحاجة للأشياء الأخرى ( LivingEntity ، Entity ، ItemEntity ) ، و IMO من الأفضل أن تكون متسقًا في المعلومات التقنية بدلاً من أن تكون صحيحة نحويًا.

إغلاق هذا لأن معظمهم ضده.