Godot: المتغيرات أو الوظائف الخاصة في GDScript

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

YeldhamDev للأسف ، setget مفيد ولكن إذا كنت لا تريد رؤية ملكية عامة - فلا توجد طريقة للقيام بذلك. هذا سيء ، reduz ما رأيك؟

إنه غير ممكن في Python أيضًا: حتى الشرطة السفلية المزدوجة البادئة لا تمنعك من الوصول إلى المتغيرات وتعديلها. في Python ، تستخدم الاصطلاحات بدلاً من ذلك: شرطة سفلية أولية للإشارة إلى متغير خاص ، ALL_CAPS للإشارة إلى شيء ما ثابت ... لا يزال من الممكن الوصول إليها من أي مكان ولكنها في الواقع ليست مشكلة.

NathanLovato ربما يجب أن يختلف GDScript عن Python في هذه الحالة؟

Chaosus يجب عليك تقديم الحجج لشرح سبب أهمية المتغيرات الخاصة. وإلا فمن غير المحتمل أن يعمل شخص ما على ذلك.

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

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

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

أنا لا أقول أنه لا ينبغي أن يكون في GDscript - أنا لا أمانع حقًا إذا كان الآخرون لديهم استخدام جيد لهذه الميزة. أنا فقط لست مقتنعًا بأن هذا مفيد. على سبيل المثال ، لم يتمكن Godot من سرد المتغيرات التي تحتوي على بادئة _ أو اثنين في الإكمال التلقائي (على الرغم من أنه يستخدم _function_name كمتعارف عليه للوظائف الافتراضية)؟

أنا فقط لا أريد أن أرى أساليب داخلية مع التحسس في GDScript ، وجعلها أشبه بـ C # وغيرها من اللغات المكتوبة الثابتة

نعم ، أوافق على أنه من الصعب تنفيذه ويتطلب كلمة رئيسية جديدة ، وبذل جهد كبير للحصول على نتيجة صغيرة جدًا
الحل مع البادئة "__" يحل المشكلة جزئيًا ، شكرًا (لم أعمل مع Python أبدًا ، لذا فهي شيء جديد بالنسبة لي).

أعلم أن هذا مغلق وأرشفته بالفعل (لست متأكدًا مما إذا كان يجب أن يكون هناك مشكلة أخرى مفتوحة لهذا الغرض) ، لكن معدِّلات الوصول هي ميزة مهمة جدًا في أي لغة برمجة. إذا كنت أرغب في إنشاء ملحق Node جديد لـ Godot وكانت العقدة الجديدة الخاصة بي تحتوي على متغيرات حالة داخلية لا ينبغي تعديلها خارج Node ، فلا يوجد ما يمنع حدوث ذلك. أتفهم أنه يمكنك استخدام الشرطة السفلية الأمامية لتقليد هذه الميزة ، لكنها لا تزال لا تمنع الوصول الذي يمثل النقطة الكاملة لمعدِّلات الوصول. في رأيي ، هذه مشكلة كبيرة جدًا حيث لا توجد طريقة للتحكم في الطريقة التي يتفاعل بها الآخرون مع الأشياء الخاصة بك.

نعم ، أنا أتفق مع dylmeadows أنه سيكون مفيدًا بهذه الطريقة

أنا بالتأكيد مؤيد للوظائف والمتغيرات الخاصة أيضًا.

1. نعم ، لدينا اصطلاح خاص باستخدام _ أمام اسم العمليات ، ولكن يتم استخدام نفس الاصطلاح للوظائف الافتراضية. لذلك إذا رأيت شرطة سفلية ، فقد يعني ذلك إما "لا تلمس هذه الوظيفة بأي حال من الأحوال!" أو "الكتابة فوق هذه الوظيفة!". هذا أمر خطير ، بصراحة.

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

3. اخيرا وليس اخرا؛ الإكمال التلقائي. أنا شخص يستخدم هذا كثيرًا لتعلم ما يمكن أن يفعله الفصل.
   أنا فقط أضع ذلك "." في النهاية وشاهد الوظائف المنبثقة. إذا كان هناك شيء يبدو مفيدًا ، فأنا أستخدمه.
   سيكون أنظف كثيرًا إذا لم يكن هناك تشوش بكل تلك الوظائف التي لا يُفترض أن يتم استدعاؤها على أي حال. بالإضافة إلى - ومرة ​​أخرى - ما زلت لا أعرف ما إذا كانت وظائف _name هذه خاصة أم افتراضية.

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

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

أنا أؤيد ما قاله Byteron و dylmeadows أيضًا. لقد كتبوا منشوراتهم بشكل جيد بما فيه الكفاية وقالوا بالضبط ما كنت أفكر فيه. أردت فقط إضافة سنتي.

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

Python ليست أفضل لغة تُذكر على أنها لغة مثالية.
لقد قيل أن Godot موجه للغاية. كل نص هو كائن كذلك. أحد المبادئ الرئيسية للبرمجة الموجهة للكائنات هو توفير التغليف. إذا كنت أرغب في الحصول على شيء لم يمسه من الخارج ، فمن المحتمل أن يكون ذلك لأفضل الأسباب.

أنا شخصياً لم أواجه وقتًا أحتاج فيه بشدة لمنع الأشخاص من تحرير المتغيرات أو الوصول إلى وظيفة. في أي وقت أريد فيه إخبار الأشخاص بعدم العبث بشيء ما إلا إذا كانوا يعرفون ما يفعلونه ، أقوم بإدخال بادئة على اسمه بـ _ (أو _internal_ أو ما شابه).

لن أعترض على كلمة رئيسية (أو ما شابه) من شأنها ببساطة إخفاء المتغير / الوظيفة من الإكمال التلقائي. أنا فقط لا أعتقد أن منع الوصول بشكل كامل ضروري.

من ناحية ، من الأفضل التحذير ، وليس المنع. ولكن من ناحية أخرى ، عادة ما يتم استخدام الحقول والأساليب الخاصة عدة مرات. وأسماء المتغيرات الطويلة (مثل _internal_variable ) مزعجة بعض الشيء.
على أي حال ، فإن وجود الكلمة الرئيسية private لا يجبرك على استخدامها.

أفراد الصف لشيء مثل الثوابت. وبالمثل ، يمكننا كتابة اسم المتغير بأحرف كبيرة والاتفاق على أننا لن نغير قيمته. لكننا لا نفعل ذلك ، أليس كذلك؟ بمعنى أن المتغيرات الخاصة هي تقاطع بين المتغيرات العادية والثوابت. لماذا لا تدخل كلمة أساسية خاصة لهذه الحالة؟

نعم ، لدينا اصطلاح خاص باستخدام _ أمام اسم العمليات ، ولكن يتم استخدام نفس الاصطلاح للوظائف الافتراضية. لذلك إذا رأيت شرطة سفلية ، فقد يعني ذلك إما "لا تلمس هذه الوظيفة بأي حال من الأحوال!" أو "الكتابة فوق هذه الوظيفة!". هذا أمر خطير ، بصراحة.

هذه أكبر مشكلة أراها هنا. بدلاً من private الكلمة الرئيسية ، ربما يمكننا الحصول على كلمة رئيسية virtual ؟ تظهر بعض الأساليب الافتراضية بالفعل في الإكمال التلقائي عندما تكتب "func" ، لذا فإن الكلمة الأساسية للتمييز صراحة بين الوظائف الافتراضية التي من المفترض أن تكتب فوقها والوظائف الخاصة التي لا ينبغي أن تظهر في الإكمال التلقائي قد تكون كافية. فائدة الكلمة الرئيسية virtual هي أنك ستستخدمها أقل من private ، لذا فهي أقل كتابة.

سأكون سعيدًا لرؤية أعضاء الفصل الخاص مدرجين أيضًا. هناك سبب لوجود هذا في لغات أخرى. لا يحتاج المستهلكون / أعضاء الفريق الآخرون (أو حتى أنت) إلى معرفة كيفية عمل كل فصل. في الواقع ، ربما لا ينبغي أن يكون لديهم حتى خيار العبث بالوظائف التي من المفترض أن تكون داخلية على أي حال.

أفهم أن الشرطة السفلية الرئيسية يجب أن "تشير" إلى أن هذا عضو خاص ، ولكن من الناحية العملية لا أحد يهتم إذا كان تعديله بطريقة ما يؤدي إلى إنجاز المهمة. هذا مؤلم بشكل خاص إذا كنت ترغب في استخدام بعضها كمكوِّن إضافي ويمكن للجميع تغيير ما يريدون. أرغب في التحكم الكامل في حالة أي كائن / برنامج نصي أقوم بإنشائه. إن امتلاك كائنات يمكنها تغيير أي جانب من جوانب حالتهم متى أراد شخص ما القيام بذلك يجعل إنتاج كود يمكن للآخرين استهلاكه أكثر من مجرد إزعاج.

إلى جانب كل ذلك ، سيكون من الرائع إلغاء تشويش قائمة المتغيرات / الوظائف "المتاحة".

هل يمكنني تقديم توصية واحدة إلى فريق التطوير ثم يرجى التفكير في كل هذا؟ تغيير ترتيب قائمة الإكمال التلقائي. أي var أو func لا يبدأ بحرف أو رقم يظهر في __الأسفل__ من قائمة الإكمال التلقائي. ثم عليك أن تكتب _ لترى العنصر¿ بالإضافة إلى ذلك ، سيكون من الجيد إذا كان بإمكاننا استخدام رموز غير رياضية أو منطقية في الأسماء؟ لم تجربها بعد ولكن هل سيكون العرض أو الطباعة أسماء وظائف مقبولة؟ إلخ.

بالإضافة إلى ذلك ، سيكون من الجيد لو تمكنا من استخدام رموز غير رياضية أو منطقية في الأسماء؟ لم تجربها بعد ولكن هل سيكون العرض أو الطباعة أسماء وظائف مقبولة؟ إلخ.

راجع https://github.com/godotengine/godot/issues/24785.

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

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

بدلاً من أداة الضبط الفارغة ، يمكنك أيضًا طباعة خطأ.

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

يشعر GDScript تمامًا بـ C ++ - بالنسبة لي على الرغم من حقيقة أنها لغة ديناميكية. عندما أقوم بالتبديل من كتابة التعليمات البرمجية في C ++ إلى GDScript ، أفتقد معدّلات الوصول هذه. ومع ذلك ، فإن GDScript يفتقد الدعم الكامل لـ OOP بالفعل.

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

الشيء هو أن الشرطة السفلية تستخدم أيضًا للوظائف الافتراضية ، وهناك بالتأكيد حالات تريد أن تكون فيها الوظائف الافتراضية عامة أيضًا.

ربما تخفي الوظائف ذات البادئة السفلية من العقد / الكائنات الأخرى فقط ، ولكن اعرضها للمكالمات على الذات / القاعدة.

اقتراحي هو استخدام شرطة سفلية واحدة للوظائف الافتراضية وشرطة سفلية مزدوجة للوظائف "الخاصة". بهذه الطريقة يمكننا إخفائها من الإكمال التلقائي دون التأثير على الوظائف الافتراضية.

يعد استخدام الشرطة السفلية لإخفاء متغير أمرًا سيئًا لأنه عندما تقوم بتغيير الوصول إلى _ سمة المتغير ، يجب عليك تغيير _name_ الخاص به. في الواقع ، variable و _variable اسمان مختلفان.
هذا أيضًا مثل نقطة في أسماء ملفات UNIX: قرار مثير للجدل تمامًا.

هذا رأيي

• بادئة بـ "__" للوظائف الخاصة
• لا تظهر الوظائف ذات "__" في الإكمال التلقائي
• "func x ()" هو سكر نحوي لـ "func __x ()"

ما سبق يكسر أي كود يتضمن متغيرًا مسبوقًا بـ "__". لكن ، باستثناء ذلك ، أعتقد أن هذا النظام سيكون مثاليًا.

وبالتالي فإن ميزات GDScript تشبه إلى حد بعيد Python / JS ، وكلا هاتين اللغتين لا تحتويان على متغيرات ووظائف خاصة لسبب وجيه للغاية - إنها نقيض كامل لفلسفة التصميم الخاصة بهما. لديك الحرية ، وهذه الحرية مهمة ، إنها ما يجعل البرمجة سهلة. أنت تضحي بالتغليف ، لكن هذه فلسفتهم. تم كسر التغليف الحقيقي بالفعل بدون التحقق من الكتابة [إلا إذا قمت بفحص جميع الأنواع بنفسك ، وهو ما لن تفعله على الأرجح]. لذلك ، ما لم يطبقوا كتابة صارمة ، فإن المتغيرات الخاصة تبدو خاطئة. في تدرج OOP ، تأتي الكتابة الصارمة قبل المتغيرات الخاصة. هناك العديد من اللغات ذات الكتابة الصارمة ولكن لا توجد متغيرات خاصة ، لكنني لا أعرف أي لغة بها متغيرات خاصة ولا توجد كتابة صارمة. هذا مرة أخرى ، لسبب وجيه. علاوة على ذلك ، يتيح لك JS الوصول إلى شجرة الميراث بأكملها ويتيح لك تغيير هذه الجوانب أيضًا. يمكنك تغيير أي فئة يرثها كائن أثناء وقت التشغيل ، عن طريق أي جزء من التعليمات البرمجية التي تحتوي على الكائن الخاص بك! بالطبع ، هذا لا يحدث ، لكنه يظهر فلسفة التصميم.

لذا ، في رأيي ، المتغيرات الخاصة الحقيقية ستعيق اللغة بشكل كبير. على أي حال ، أعتقد أن نظام Python يقوم بذلك بشكل جيد ، لديك __ يمكنك استخدامه للوصول إلى المتغيرات الخاصة ، لكنه يوضح أنك تعبث بشيء داخلي ، ومع ذلك فهو لا يقيدك بشكل هادف. لا يمكن لأي شخص يريد فلسفة تصميم OOP حقيقية استخدام "__" مطلقًا ، أو استخدامها في أسلوب الترميز الخاص بشركته أو مشروعه. ربما يكون خيارًا لتمييزه كخطأ أمرًا رائعًا. أعني بشكل عام أن كتابة البط والمتغيرات الخاصة لا تتوافق حقًا. على الأقل ، تقوم بإفساد مساحة الاسم تمامًا لأن ما الآن ، لا يعمل obj.set ("hi"، 5) إذا كانت "hi" خاصة؟ لكنها تعمل إذا لم تكن كلمة "hi" موجودة؟ هذا ليس منطقيًا كثيرًا ... لذا ، فإن رفضًا قويًا للغاية لإجبار القطاع الخاص على أن يتعذر الوصول إليه تمامًا بغض النظر عن ما تفعله ، هذا هو تصويتي. نعم قوي جدًا لوجود المتغيرات الخاصة بالطريقة التي تقوم بها Python حاليًا. Tbh ما زلت غير متأكد من كيفية حل مشكلة كتابة البط باستخدام المتغيرات الخاصة على أي حال ، حتى لو كانت الرغبة في الحصول على متغيرات خاصة حقًا ولا يمكن الوصول إليها. أعتقد أنك قمت فقط بحظر obj.set وجعله يلقي بخطأ. يحتاج obj.set الآن إلى إرجاع قيمة منطقية على ما يبدو ، وهو أمر غريب. هل هي مكالمة خاصة؟ التي يجب عليك الاتصال بها قبل كل استخدام لـ obj.set؟ لا أعلم

[يا إلهي في الحقيقة ، هل يمكننا الحصول على اكتشاف فعلي للأخطاء ، نحن نتحدث عن المتغيرات الخاصة ولكن اعتبارًا من الآن إذا كان لديك خطأ في gdscript ، فستتجاهله اللعبة بصمت (facepalm). ربما أفعل ذلك بشكل خاطئ ، ولكن إذا كان أي كود خاص بي يفعل شيئًا غير قانوني يبدو أنه يعود فارغًا من الوظيفة ، مما يجعل من الصعب جدًا تعقبه ، فإن JS كانت بهذا السوء و JS هي فوضى للغة. أعلم أن تعطل اللعبة قد يكون أكثر من اللازم ، لكني ما زلت مضطرًا إلى البحث الثنائي في قاعدة الشفرة الخاصة بي عن طريق وضع عبارات مطبوعة حتى أجد عبارتين متتاليتين للطباعة حيث لا تتم الطباعة الأولى والأخيرة ، فقط لمعرفة مكان كسر الكود. JS / Python أكثر صرامة بشكل مدهش بهذا المعنى ، على الرغم من مدى حريتهم في كل شيء آخر.]

أقترح العثور على منظمة مشروع متسقة لتقليل المشكلة. يمكنك استخدام العقدة الجذرية للمشهد كواجهة للتحكم في المشهد من الخارج ونص فرعي كخلفية.

بدلاً من ذلك ، يمكنك استخدام الطرق فقط ، وتصدير المتغيرات ، والإشارات ، ولا تلمس أبدًا المتغيرات البسيطة من الخارج. هذه اتفاقية بسيطة ويمكن لـ GDScript الحفاظ على بساطتها.

إنه غير ممكن في Python أيضًا: حتى الشرطة السفلية المزدوجة البادئة لا تمنعك من الوصول إلى المتغيرات وتعديلها. في Python ، تستخدم الاصطلاحات بدلاً من ذلك: شرطة سفلية أولية للإشارة إلى متغير خاص ، ALL_CAPS للإشارة إلى شيء ما ثابت ... لا يزال من الممكن الوصول إليها من أي مكان ولكنها في الواقع ليست مشكلة.

أريد فقط أن أقول ، أنه من الممكن أن يكون لديك سمة _private_ في بايثون.

اقتباس (https://www.python.org/dev/peps/pep-0008/):

__double_leading_underscore: عند تسمية سمة فئة ، استدعاء mangling الاسم (داخل الفئة FooBar ، __boo تصبح _FooBar__boo ؛ انظر أدناه).

__ double_leading_and_trailing_underscore__: كائنات أو سمات "سحرية" تعيش في مساحات أسماء يتحكم فيها المستخدم. على سبيل المثال __init__ ، __import__ أو __ملف__. لا تخترع مثل هذه الأسماء ؛ استخدمها فقط كما هو موثق

إذا قمت بالنقر فوق هذا الارتباط و CTRL + F "خاص" ستحصل على

نحن لا نستخدم مصطلح "خاص" هنا ، حيث لا توجد سمة خاصة حقًا في Python (بدون قدر غير ضروري من العمل بشكل عام).

تعمل متغيرات الشرطة السفلية المزدوجة أو المتغيرات السفلية المفردة تمامًا مثل المتغيرات العادية ، إنها مجرد اصطلاح للإشارة إلى أنه لا ينبغي استخدامها وقد تتغير عند تحديث مكتبة لأنها داخلية. بشكل عام ، نظرًا لأن اللغات Pythonic مثل GDScript تعامل الكائنات كما لو كانت مجرد قواميس ، فسيكون من الصعب محاولة فرض المتغيرات الخاصة وجعلها تستهلك مساحة الاسم.

إذا قمت بالنقر فوق هذا الارتباط و CTRL + F "خاص" ستحصل على

نحن لا نستخدم مصطلح "خاص" هنا ، حيث لا توجد سمة خاصة حقًا في Python (بدون قدر غير ضروري من العمل بشكل عام).

تعمل متغيرات الشرطة السفلية المزدوجة أو المتغيرات السفلية المفردة تمامًا مثل المتغيرات العادية ، إنها مجرد اصطلاح للإشارة إلى أنه لا ينبغي استخدامها وقد تتغير عند تحديث مكتبة لأنها داخلية. بشكل عام ، نظرًا لأن اللغات Pythonic مثل GDScript تعامل الكائنات كما لو كانت مجرد قواميس ، فسيكون من الصعب محاولة فرض المتغيرات الخاصة وجعلها تستهلك مساحة الاسم.

أوافق ، فهم لا يسمونها سمة _ خاصة_. ومع ذلك ، اسمحوا لي أن أصف كيفية عملها:

# defining class Employee
class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.__salary = salary

>>> emp = Employee("Bill", 10000)
>>> emp.__salary
# AttributeError: 'employee' object has no attribute '__salary'

لذلك لا يطلق عليها سمة _private_ ، لكنها تتصرف مثلها تقريبًا .
سيكون من الرائع أن يكون لديك سمة خاصة تقريبًا في GDScript كما هي موجودة في Python.

أوه نعم ، أنا أتفق معك بشدة. تمنحك Python ببساطة سكرًا نحويًا لاستخدام ._Employee_salary. أنا شخصياً لا أحب الطريقة التي يستخدمها البايثون وأعتقد أنه يمكن تحسينها بقوة في Godot ، كما ذكرت في تعليقي ،

class Employee:
      var name # normal
      private var salary # Syntactic sugar for var _salary

وهو أكثر نظافة لأن الراتب _Employee__ هو طريقة قبيحة لإخفاء اسم المتغير ، ووجود كلمة رئيسية خاصة يجعلها مثل OOP العادي. والأفضل من ذلك ، أن هذا يمنع القدرة على الحصول على راتب عام متغير وراتب متغير خاص ، والذي سيكون قبيحًا ويجب أن يكون خطأً في بناء الجملة تمامًا كما هو الحال في Java. هذا لأنه سيتم الإعلان عن كلاهما "راتب متغير" و "راتب متغير خاص" ، وهو تضارب واضح. هناك طريقة أخرى للتفكير وهي "من أجل الوصول إلى متغير خاص من فئة C أخرى مع العضو m ، عليك استخدام شرطة سفلية كما في C._m". يمكننا بعد ذلك أن نخطئ في إعلان متغير يبدأ بشرطة سفلية ، أي جعل الخصوصية هي الطريقة الوحيدة للإعلان عنه ، بحيث يكون من الواضح ما يتم فعله.

أعتقد أن السبب الوحيد لوجود موقف غير مرغوب فيه في Python هو أنه لا توجد تصريحات في الجزء العلوي للمتغيرات ، فأنت فقط تصنع متغيرات الصنف في أي من أجسام الوظائف. يبدو أن GDScript يتطلب إعلانات في نص الفصل ، مما يمنحه مقطعًا سهلاً في الإعلانات الخاصة الشبيهة بجافا.

أنا لست مغرمًا بامتلاك كلمات رئيسية تعمل كسكر تركيبي ما لم توفر الكثير من الكتابة. هنا ، ستجعلك كتابة private تكتب المزيد من الأحرف ، مما يجعلها اختصارًا مضادًا للاختصار: قليلاً_ابتسامة_الوجه:

أيضا ، ماذا عن الأساليب؟ تبدأ عدة طرق افتراضية بشرطة سفلية ، لذلك لا يمكننا استخدام شرطة سفلية واحدة لتمييزها على أنها خاصة. ومع ذلك ، يمكننا استخدام شرطين تحت السطر ، مما يتجنب التعارضات على حساب كونه أطول. أحب أيضًا فكرة اتباع اتفاقيات Python عندما يكون ذلك منطقيًا - لقد كان "dunder" شائعًا لبعض الوقت في تلك اللغة.

لا أعتقد أن القصد من ذلك هو أن يتم عرضه على أنه اختصار ، ولكن الفكرة هي أنه خارج الفصل الدراسي ، يمكنك استخدام "_" للوصول إلى المتغيرات الخاصة. السكر النحوي هو كيفية تنفيذه. مطابق بشكل أساسي لكيفية قيام الثعبان بذلك. ولكن كما هو الحال ، هذا صحيح ، في حالة بيثون ، يوفر السكر النحوي الكثير من الكتابة ، ولكن هذا فقط لأنه ينسب إلى شيء غبي طويل الأمد. إن الاسم المستعار لشيء أقصر هو الأفضل تمامًا ، لذا فإن امتلاك اسم مستعار أقصر ثم اختيار عدم امتلاك سكر بناء الجملة لأن الاسم المستعار قصير جدًا ، يتلخص فقط في ما إذا كان ينبغي علينا دعم المتغيرات الخاصة على الإطلاق أم لا ؛ لسنا مضطرين لذلك ، يمكننا فقط أن نجعل المستخدمين يعتمدون على المتغيرات ذات الشرطات السفلية أو اختيار الاصطلاح الخاص بهم. إنه مخصص فقط للأشخاص الذين يفكرون في استخدام Java و C ++ ، والذين يفضلون كتابة "private var myvariable" بدلاً من مجرد اعتبار "_myvariable" خاصًا مثل الاتفاقية ، الأمر الذي يبدو غريبًا عند القدوم من عالم OOP ، حتى لو كان كلاهما ينجز بالضبط نفس الشيء. تتطابق الشرطة السفلية المزدوجة مع بناء جملة بايثون جيدًا ، لذلك أنا مستعد لذلك أيضًا ، خاصة إذا كان _ يتعارض مع أشياء أخرى

أفضل أن يكون لدي كلمة رئيسية تحدد السلوك بشكل صريح خارج ما يمكن تفسيره بشكل خاطئ على أنه اصطلاحات أسلوب فقط. private يحصل على تصويتي.

إضافة نار إلى المناقشة: إن اصطلاح نمط Python للأعضاء "الخاصين" هو إضافة شرطة سفلية قبل الاسم ، والتي تستخدم بالفعل بواسطة gdscript لغرض مختلف في طرق الأحداث الشائعة مثل _ready() ، _input و _physics_process على سبيل المثال لا الحصر. هل من المفترض أن تكون هذه خاصة؟ كيف ستتفاعل إضافة كلمة رئيسية خاصة مع هذه الأساليب؟ هل يلزم أيضًا تنفيذ كلمات رئيسية أخرى مثل protected ؟

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

نعم ، شخص ما لاحظ ذلك بالفعل. (انظر رد كالينو) شرطة سفلية مزدوجة ستكون السبيل للذهاب. مثل بايثون أيضًا.

2 ج. في Python ، لا شيء يمنع أي شخص من الوصول إلى أعضاء الفصل الذين يبدأون بـ _ ، ومع بعض المعرفة الداخلية بـ __ أيضًا.

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

تضمين التغريدة

1. GDScript ليس لغة Python.
2. باتباع المنطق الخاص بك ، ليست هناك حاجة أيضًا إلى الثوابت (var CONSTANT = 1).
3. لا يحب الجميع استخدام __ .

أنا من أجل الكلمة الرئيسية private ، فلن يفسد ذلك التوافق.
بدلاً من ذلك ، جعل func و var خاصين باستخدام _ ، من شأنه أن يغير الأشياء لعدد قليل من استخدامها لأسباب أخرى (أستخدم _ فقط في معلمات الوظيفة ).

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

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

فقط لإضافة صوت واحد آخر لإضافة كلمات رئيسية خاصة ومحمية.
إذا سبق لك أن كتبت رمزًا سيستخدمه مطور آخر ، فلا يمكنك أن تعارض ذلك.
كل شيء ضد إضافة كلمة رئيسية يمكن التحقق من هذا الموضوع:
https://softwareengineering.stackexchange.com/questions/143736/why-do-we-need-private-variables

ما زلنا في طريقنا لاستخدام GDscript ولكن لماذا لا نجعله أفضل في هذه العملية.

_ ، __ ، ___ ، وما إلى ذلك من الغباء تمامًا مثل إضافة بادئات لأسماء المتغيرات لاقتراح الأنواع
intAge ، strName ، bIsAlive ... كل هذه تظهر فقط ميزات اللغة المفقودة.
لذلك حتى بدون مقارنة GDScript مع Python أو لغات أخرى ، يمكن للمطور إجراء استطلاع لمعرفة هل تريد أو لا تريد الأغلبية هاتين الكلمتين الرئيسيتين ؛)

إذا تم تنفيذ الميزة ، آمل أن يتم اختيار طريقة C ++. الكلمة الأساسية "خاصة" أو "عامة" أمام كل إعلان تجعل C # مرهقًا للقراءة.

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

private var foo : String = "foobar" أكثر انسجامًا مع استخدام الكلمات الرئيسية الحالية export و onready أيضًا.

الإغلاق لصالح https://github.com/godotengine/godot-proposals/issues/641 ، حيث يتم الآن تتبع مقترحات الميزات في مستودع مقترحات Godot.