Yarn: نص -> TextComponent

تم إنشاؤها على ٢٦ أغسطس ٢٠١٩  ·  23تعليقات  ·  مصدر: FabricMC/yarn

لماذا تم إعادة تسمية هذا؟ المكون هو اسم 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 (نص عادي ، نص بنمط ، روابط ، إلخ) للحصول على المكون ، انتهى الماوس.

discussion refactor

التعليق الأكثر فائدة

لم أستخدم التكرار أبدًا مرة واحدة على رسالة ، وأشك في أن العديد من المودعين قد استخدموا ذلك أيضًا. أنا بخير مع TextComponent لكن المكون غامض وغير مفيد لـ 99.9٪ من الأماكن التي يستخدمها الناس بالفعل في التعديلات.

ال 23 كومينتر

لماذا تم إعادة تسمية هذا؟

737 # 650

لا أتفق مع المكون لأنه عام للغاية.

ما زلت أؤيد اقتراح اللاعب بـ 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)

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

asiekierka picture asiekierka  ·  4تعليقات

Sollace picture Sollace  ·  5تعليقات

haykam821 picture haykam821  ·  4تعليقات

Awakened-Redstone picture Awakened-Redstone  ·  4تعليقات

Runemoro picture Runemoro  ·  4تعليقات