أولاً ، يُطلق على فئة الكتلة اسم CommandBlock
، وليس CommandBlockBlock
، كما أنها تجعلها أقل ازدحامًا بالاسم. يبدو أن هذا قد يكون قطعة أثرية من البادئة -> نقل اللاحقة.
إنه CommandBlock
BlockEntity
وليس CommandBlockBlock
Entity
ولكن وفقًا لهذا المنطق ، يجب تسمية فئة CommandBlock
CommandBlockBlock
.
لقد حصلت على نقطة ^ ^
عدل.
أنا شخصياً أعتقد أنه يجب أن تكون هناك لاحقة بلوك مزدوج. نظرًا لأنها كتلة (Note Block) ، وليست كتلة (Note)
ولكن بناءً على هذا المنطق ، يجب تسمية فئة CommandBlock باسم CommandBlockBlock.
أعتقد أنه ينبغي.
أيضًا ذات صلة هنا هي كتل grass
و grass_block
. لست متأكدًا من كيفية تسميتها حاليًا ، ولكن ربما ينبغي النظر فيها في هذا السياق
أنا من أجل CommandBlockBlock
أليست اللاحقة تهدف إلى توضيح نوع الفصل؟ يحتوي CommandBlock بالفعل على block لأنه لاحقة تم إنشاؤها من mojang للإشارة إلى أوامر من نوع block. ليس هناك حاجة BlockBlock هنا.
باستثناء الكتلة ليست اللاحقة ؛ الفئة الأساسية بأكملها هي. في هذه الحالة ، ستكون لاحقة أي فئة فرعية من BlockEntity هي BlockEntity - كما هو الحال مع كل فئة أساسية أخرى في التعيينات الحالية - وتكون بادئة كل فئة فرعية من BlockEntity هي اسم الفئة بالكامل للكتلة ، بما في ذلك بادئة اسم الفئة هذا ، وبالتالي فإن البادئة هي CommandBlock واللاحقة هي BlockEntity.
يمكن قراءة إزالة إحدى الكتل كبادئة CommandBlock مع لاحقة الكيان - مما يعني أنها فئة فرعية من الكيان للوهلة الأولى - بادئة الأمر بلاحقة BlockEntity - مما يعني أنها BlockEntity لكتلة تسمى Command وليس CommandBlock للوهلة الأولى - أو ببساطة كشكل مختصر من CommandBlockBlockEntity ، وبالتالي إدخال الغموض.
ومع ذلك ، يجب أن يعرف معظم الناس الآن أن CommandBlocks لديها BlockEntities وليست كيانات عادية وأن CommandBlock يبدأ بالأمر. ومع ذلك ، فإن الطريقة الحالية تتوافق مع بقية التعيينات ، والاتساق يجعل الأمور أسهل ، حتى لو لم تتدحرج على اللسان بنفس السهولة.
الطريقة الحالية متوافقة مع بقية التعيينات
لا أعتقد ذلك ، لأن CommandBlock
ليس CommandBlockBlock
. ومع ذلك ، فإن وجهة نظرك بشأن الغموض جيدة.
التعليق الأكثر فائدة
أنا من أجل CommandBlockBlock