لماذا تم إعادة تسمية هذا؟ المكون هو اسم Mojang ، وتسميته بـ "Text" فقط يجعل الكود مثل هذا مربكًا:
public Text method_2164(int mouseX) {
if (message == null) {
return null;
}
int width = minecraft.textRenderer.getStringWidth(message.asFormattedString());
int x1 = this.width / 2 - width / 2;
int x2 = this.width / 2 + width / 2;
int x = x1;
if (mouseX < x1 || mouseX > x2) {
return null;
}
for (Text t : message) {
x += minecraft.textRenderer.getStringWidth(TextComponentUtil.getRenderChatMessage(t.asString(), false));
if (x > mouseX) {
return t;
}
}
return null;
}
بالنظر إليها سريعًا ، قد تعتقد أن message
عبارة عن قائمة نصوص (على سبيل المثال السطور) ، ولكن في الواقع ، تتكرر الشفرة عبر المكونات المختلفة لـ message
(نص عادي ، نص بنمط ، روابط ، إلخ) للحصول على المكون ، انتهى الماوس.
لماذا تم إعادة تسمية هذا؟
لا أتفق مع المكون لأنه عام للغاية.
ما زلت أؤيد اقتراح اللاعب بـ Text
لإيجازه ووضوحه. علاوة على ذلك ، نحن نتحرك بعيدًا عن المصطلحات الغامضة الأخرى (مثل حاوية -> اقتراح قائمة)
في المثال الخاص بك ، أعتقد أن إعادة تسمية فئة TextComponentUtil
إلى TextRenderUtil
/ TextRenderHelper
وطريقتها getRenderChatMessage
إلى handleColor
هي حل أفضل لإعادة التسمية فئة Text
.
عنصر تمتص موضوعيا. لقد مررنا على هذا عشرات المرات. نحن لن نتجاوزها مرة أخرى.
يجب أن يأتي الوضوح وسهولة الاستخدام دائمًا أولاً فوق التناسق مع Mojang. من الجيد أن يكون لديك هذا الأخير ، ولكن ليس أبدًا على حساب الأول.
الوضوح وسهولة الاستخدام
هل قرأت القضية حتى؟ المشكلة هي أنها محيرة.
ليس من المنطقي "تكرار نصوص الرسالة". من المنطقي التكرار من خلال مكونات الرسالة.
هناك سياسة (ناعمة) لاستخدام أسماء Mojang حيث نعرفها
الكلمات الرئيسية لينة . إذا قررنا أن الاسم سيء من أجل الفهم ، فلن نستخدمه.
بصراحة ، أنا شخصياً لن أختار Text
كاسم أيضًا. ومع ذلك ، فهو أفضل بكثير من Component
، لأنه يصف في الواقع ما يُستخدم لـ (النص) بدلاً من كونه اسمًا عامًا لـ "جزء من شيء ما" لا معنى له خارج السياق. TextComponent
سيكون حلًا وسطيًا لطيفًا ، لكني أعتقد أن هذا لن يكون شائعًا تمامًا مع معرفة هذا المجتمع.
الكلمات الرئيسية لينة.
القائمة اسم رهيب وتريد استخدامه. (نص) المكون هو اسم جيد ولا تريد استخدامه.
هل يمكن أن تخبرني أيهما أكثر منطقية بالنسبة لك؟
for (Component component : message) {
for (Text text : message) {
لم أستخدم التكرار أبدًا مرة واحدة على رسالة ، وأشك في أن العديد من المودعين قد استخدموا ذلك أيضًا. أنا بخير مع TextComponent لكن المكون غامض وغير مفيد لـ 99.9٪ من الأماكن التي يستخدمها الناس بالفعل في التعديلات.
ليس من المنطقي "تكرار نصوص الرسالة". من المنطقي التكرار من خلال مكونات الرسالة.
يصبح التكرار من خلال نص json أو نص منسق أمرًا منطقيًا بعد ذلك.
for (Component component : message) {
المشكلة أن الشيء ليس message
؛ إنه siblings
بدلاً من ذلك. النص الأول الذي يحتوي على كل هذه الأجزاء الفرعية في الدفق هو بالفعل النص الكامل في الذاكرة.
Boundarybreaker Yarn لا تقوم فقط بتعيين ما تستخدمه.
ليس لدي مشكلة مع TextComponent أيضًا.
أنا أحب كل من Text و TextComponent ، لكن المكون غامض للغاية.
Yarn هو نظام لفهم كود Minecraft للأشخاص ليكونوا قادرين على إنشاء تعديلات ، لذا فإن مكان وزمان استخدام الأشخاص للفصل هو مفتاح لكيفية اتخاذ قرار بشأن الأسماء التي يجب استخدامها. يكون لفهم الاستخدامات الأكثر شيوعًا للفئة أسبقية أعلى للاسم الذي يكون أكثر دقة بالنسبة للاسم الداخلي لـ Mojang.
يستخدم الغزل أيضًا الأشخاص الذين يرغبون في فهم كيفية عمل رمز الفانيليا.
يكون لفهم الاستخدامات الأكثر شيوعًا للفئة أسبقية أعلى للاسم الذي يكون أكثر دقة بالنسبة للاسم الداخلي لـ Mojang.
بالتأكيد ، ولكن هناك اسم يقوم بكليهما: TextComponent
في هذه المرحلة ، يتعين علينا حقًا التفكير في فوائد تغيير اسم هذه الفئة للمرة الثالثة.
حجج لتغييره:
Component
غير دقيق. يمكن أن يتداخل النص ، ولا يوجد في تعريفه ما ينص على أنه يجب أن يكون هو الشيء الكامل.الحجج ضد تغييره:
Text
في سياقات التطوير العادية.لقد ناقشنا هذا بالفعل في Discord ، لذلك سأكرر اقتراحاتي:
for (Fragment fragment : message)
و
for (TextFragment fragment : message)
يتناسب هذا مع سرد ماهية الرسالة. يمكن اعتبار أي جزء من النص جزءًا ، ويمكن تقسيم أي نص إلى أجزاء أخرى من النص. أيضًا في اللغة ، يُطلق على جزء من النص ليس في حد ذاته جملة كاملة ، إن لم يكن عبارة ، "جزء".
الشظية هي أيضًا قطعة ، أو جزء ، شظية. على سبيل المثال _Fragmentation_.
يمكنك سماع جزء من محادثة ، أو كتابتها على أنها جزء من نص. ثم قم بتمزيق الصفحة وتخلص من الشظايا.
هذا لا يعني أنني لا أحب Text
، أنا بخير. يتمتع Text
بجميع مزايا TextFragment
وهو أقصر من ذلك. كل الأشياء تعتبر جيدة مثل TextFragment
، _ بالتأكيد أفضل من TextComponent
و _waaaaaaay_ أفضل من Component
فقط. لن أغيره.
TextFragment
أفضل قليلاً من TextComponent
، لكنه بعيد عن اسم mojang مثل النص. أعتقد أن Text
هو بالفعل الخيار الأفضل للاثنين.
أود أن أسميها TextTreeNode
لأن هذا هو الاسم الأكثر تطابقًا مع سلوكه.
TextTreeNode setStyle(Style var1);
Style getStyle();
TextTreeNode addChild(String string_1);
TextTreeNode addChild(TextTreeNode var1);
String getContent(); // only self
String getString(); // whole tree, overrides brigadier message api, no format
String getString(int maxLength); // whole tree, truncated result possibly
String getFormattedString(); // whole tree
List<TextTreeNode> getChildren();
Stream<TextTreeNode> streamTree();
Stream<TextTreeNode> streamCopiedTreeNodes();
Iterator<TextTreeNode> treeIterator();
TextTreeNode copy(); // copy this node
TextTreeNode formattedDeepCopy(); // copy the whole tree with style
TextTreeNode format(Consumer<Style> consumer_1); // accept the style
TextTreeNode format(Formatting... formattings_1); // mutates the node
TextTreeNode format(Formatting formatting_1); // mutates the node
static TextTreeNode formattedCopy(TextTreeNode text_1); // copy this node with style
ولكن على الرغم من أنها حقًا عُقد شجرية ، إلا أنه ليس لدينا فئة مقيدة لتقديم الشجرة بأكملها ، وبالتالي ما زلت أؤيد الاسم Text
.
حسنًا ، حان الوقت لإنهاء هذه الحجة. أفترض أنه يمكننا إغلاق هذه القضية بأمان نظرًا لمقدار المعارضة للقضية
liach العديد من التعليقات هنا و Discord توافق على أن Text
ليس اسمًا جيدًا. إذا لم يكن TextComponent
، فيجب إعادة تسميته إلى شيء آخر. ربما TextPiece
؟
قارن هذه:
هل تمانع في إجراء تصويت في عدد جديد؟ على الرغم من أن نص ماين كرافت قبيح ، إلا أنه لا يوجد سوى نوع واحد من النص في ماين كرافت ، لذلك أقول إن الاسم "نص" كافٍ ، بينما هناك عناصر أخرى شبيهة بالمكونات (مثل FoodComponent)
التعليق الأكثر فائدة
لم أستخدم التكرار أبدًا مرة واحدة على رسالة ، وأشك في أن العديد من المودعين قد استخدموا ذلك أيضًا. أنا بخير مع TextComponent لكن المكون غامض وغير مفيد لـ 99.9٪ من الأماكن التي يستخدمها الناس بالفعل في التعديلات.