Godot: GDScript में एनोटेशन

बस इसलिए मैं कस्टम एनोटेशन को सही ढंग से समझ रहा हूं, मेरे पास ऐसा कुछ हो सकता है:

<strong i="6">@description</strong> "Adds two numbers and returns the result."
<strong i="7">@parameter</strong> name=num1 type=float description="The first number"
<strong i="8">@parameter</strong> name=num2 type=float description="The second number"
<strong i="9">@returns</strong> type=float description="num1 and num2 added together"
func add(num1, num2):
    return num1 + num2

और मैं एक फ़ंक्शन को कॉल कर सकता हूं, get_annotations("add") कहें, जो इन एनोटेशन को वापस कर देगा? भले ही इन एनोटेशन को गोडोट द्वारा कुछ बिल्ट-इन कीवर्ड/एनोटेशन के रूप में मान्यता न दी गई हो?

@LikeLakers2 हाँ, यही इसका सार है।

मुझे यह पसंद है, मैं इसके पीछे कार्यान्वयन के बारे में नहीं जानता लेकिन जीडीस्क्रिप्ट कोड में यह अब जैसा दिखता है उससे कहीं अधिक साफ दिखाई देगा। विशेष रूप से सेटगेट उदाहरण के लिए।

यह बहुत उपयोगी है, लेकिन इसे पठनीयता के लिए सिंगल लाइन स्टेटमेंट की अनुमति देनी चाहिए। उदाहरण के लिए,
<strong i="6">@onready</strong> var a = $A की अनुमति दी जानी चाहिए। अन्यथा, यह एक टन न्यूलाइन जोड़ता है और इस मामले में पहले से ही उपयोगी बर्बाद कर देगा।

कुछ इस तरह

<strong i="10">@onready</strong>
    var a = $A
    var b = $B
    var c = $C

एक ही एनोटेशन को कई बयानों पर लागू करने के लिए उपयोगी होगा।

साथ ही, एक कोलन का उपयोग यह इंगित करने के लिए किया जा सकता है कि एनोटेशन कहाँ समाप्त होता है और प्रभावित कथन कहाँ से शुरू होता है, शेष GDScript के साथ संगत होने के लिए।

यदि एनोटेशन को स्पष्ट शुरुआत और अंत के साथ पार्स किया जा सकता है, तो अर्धविराम की कोई आवश्यकता नहीं है और यदि आवश्यक हो तो उसी पंक्ति पर रखा जा सकता है (यदि वे उदाहरण के लिए '()' का उपयोग करते हैं, या तर्क-रहित हैं)

मुझे नहीं लगता कि vnen का इरादा पुराने शॉर्टकट कीवर्ड को हटाने का है?

इसके अलावा हाइलाइटर हैंडल होने से ये मदद कर सकते हैं।

यहां पार्टी के लिए देर हो चुकी है, लेकिन इस बात में बहुत दिलचस्पी है कि यह निर्यात युद्धों के लिए श्रेणियां कैसे प्रदान कर सकता है और टूल/डीबग स्क्रिप्ट डिवीजन बना सकता है?

अस्थायी रूप से 3.2 रोडमैप पर डालते हुए, मैं वास्तव में संपादक को उपयोगिता वृद्धि प्रदान करने के लिए इसे जल्द से जल्द लागू होते देखना चाहता हूं।

#### अलोकप्रिय राय आने वाली:

जीडीस्क्रिप्ट के सिंटैक्स को इतनी भारी मात्रा में क्यों संशोधित किया जा रहा है? यह मूल रूप से सरल, सीखने में आसान और सहज होने के लिए डिज़ाइन किया गया था। मुझे इन सभी नए परिवर्धन (टाइप किए गए जीडीएस, एनोटेशन) से डर लगता है, यह नए डेवलपर्स के लिए बहुत भ्रमित हो जाएगा। उदाहरण के लिए, यदि गोडोट के लिए कोई नया व्यक्ति एक ट्यूटोरियल देखता है और लाइकलाकर्स 2 की पोस्ट में कोड देखता है, तो मुझे लगता है कि इससे उनका सिर फट जाएगा। अगर कुछ भी हो तो उन्हें इसके बारे में प्रश्नों का गुच्छा पूछना होगा/यह कैसे काम करता है, इत्यादि।

मैं जीडीएस के लिए हर किसी के प्यार को पूरी तरह से समझता हूं और कैसे योगदानकर्ता इसे बेहतर बनाना चाहते हैं, आदि। मुझे ऐसा लगता है कि वास्तविक गेम देवों और योगदानकर्ताओं के बीच एक संभावित डिस्कनेक्ट हो सकता है (यह नहीं कह रहा है कि योगदानकर्ता गेम देव नहीं हैं, बस यह कह रहे हैं कि कैसे कुछ सुविधाओं की वास्तव में आवश्यकता नहीं है)। हर किसी को इन सुविधाओं का उपयोग करने की आवश्यकता नहीं है। मुझे बस इस बात का डर है कि कहीं gds अपनी सादगी से कहीं और भटक न जाए, बस। यह पहले से ही अधिक पर्याप्त से है ...

साथ ही, एक पंक्ति में सब कुछ निर्दिष्ट करने की तुलना में निर्यात कीवर्ड के लिए 3 लाइनें होना बहुत बोझिल है। उदाहरण के लिए: onready var my_sprite = $Sprite इतना अधिक क्लीनर है (वैसे भी मेरे लिए)

और बिंदु # 4 के संबंध में, यह संपादक AFAIK में किया जा सकता है। इसके अलावा, आईएमओ, कोड में सभी जगहों पर 'कुछ चेतावनियों को अक्षम' करने के लिए एनोटेशन होने से बहुत गन्दा कोड हो सकता है

जीडीस्क्रिप्ट के सिंटैक्स को इतनी भारी मात्रा में क्यों संशोधित किया जा रहा है? यह मूल रूप से सरल, सीखने में आसान और सहज होने के लिए डिज़ाइन किया गया था। मुझे इन सभी नए परिवर्धन (टाइप किए गए जीडीएस, एनोटेशन) से डर लगता है, यह नए डेवलपर्स के लिए बहुत भ्रमित हो जाएगा।

अधिकांश (यदि सभी नहीं) GDScript सिंटैक्स परिवर्तन पुराने कोड के साथ संगत हैं। मुख्य लक्ष्य GDScript का उपयोग करने वाले डेवलपर्स की उत्पादकता बढ़ाना है, जैसे:

• match स्टेटमेंट स्विच-केस स्टेटमेंट (जो काफी अनुरोध किए गए थे) के लिए अनुमति देते हैं और यहां तक ​​​​कि लोगों को सरणियों और शब्दकोशों को आसानी से मिलान करने की अनुमति देकर इसमें सुधार करते हैं।
• onready चर (जो 2.x में नए थे) एक पैटर्न को ठोस बनाते हैं जिसका अक्सर उपयोग किया जाता था, अर्थात् _ready में चर प्रारंभ करना।
• टाइप की गई GDScript डेवलपर्स को यह जानकर आराम करने की अनुमति देती है कि कोई गलत-प्रकार की त्रुटि नहीं होगी, और उन्हें एक ही समय में बेहतर स्वत: पूर्ण से लाभ उठाने देता है। यह वैकल्पिक है, इसलिए नवागंतुकों को अपने पहले गेम के लिए इसे सीखने की आवश्यकता नहीं है।

मुझे ऐसा लगता है कि वास्तविक गेम देवों और योगदानकर्ताओं के बीच एक संभावित डिस्कनेक्ट हो सकता है।

यह एक खुला समुदाय है। गेम देवों का स्वागत है कि वे आएं और अपनी राय व्यक्त करें, जैसा आपने किया था। किसी भी मामले में, टिप्पणियों के एक वास्तविकता बनने से पहले काफी समय बीत जाएगा।

[...] मुझे बस डर है कि जीडीएस अपनी सादगी से आगे और आगे भटक सकता है, बस। यह पहले से ही पर्याप्त से अधिक है ...

यदि यह पहले से ही काफी अच्छा होता, तो हमें इसके लिए फीचर अनुरोध प्राप्त नहीं होते।

साथ ही, एक पंक्ति में सब कुछ निर्दिष्ट करने की तुलना में निर्यात कीवर्ड के लिए 3 लाइनें होना बहुत बोझिल है। उदाहरण के लिए: पहले से ही var my_sprite = $Sprite इतना अधिक स्वच्छ है

सिंटैक्स अभी तक अंतिम रूप नहीं दिया गया है। यह बहुत संभव है कि यह onready और export कीवर्ड को तुरंत प्रतिस्थापित नहीं करेगा।

मुझे वास्तव में यह विचार पसंद है, सी # में विशेषताओं की तरह।

कक्षाएं और सिग्नल एनोटेशन भी दिलचस्प हो सकते हैं।

इंस्पेक्टर प्लगइन्स जो स्वचालित रूप से कार्रवाई में आते हैं, चाहे किसी संपत्ति, विधि या वर्ग में एक विशेष कस्टम एनोटेशन हो, एक हवा होगी।
वाक्य रचना के लिए मैं कुछ ऐसा पसंद करूंगा जो वैकल्पिक रूप से एक पंक्ति पर भी लिखा जा सके, लेकिन यह इतना महत्वपूर्ण नहीं है।

कस्टम एनोटेशन को परिभाषित करने की प्रक्रिया कैसी हो सकती है? मैं यह पसंद करूंगा कि उन्हें कोड में हर बार स्वतंत्र रूप से परिभाषित नहीं किया गया था, लेकिन यह कि वे उपयोगकर्ता द्वारा कक्षाओं की तरह एक अनौपचारिक परिभाषा के साथ बनाए गए थे।

मुझे लगता है कि इसे और अधिक देखने की जरूरत है, मुझे लगता है कि भाषा में जोड़ना बहुत अच्छा होगा (वैकल्पिक वाक्यविन्यास इत्यादि के रूप में) ताकि कूदने की कोशिश कर रहे पूर्ण नए लोगों को भ्रमित न किया जा सके।

मुझे लगता है कि निम्नलिखित वाक्यविन्यास देखने के लिए ठीक हो सकता है:

<strong i="7">@export</strong> type=String, hint=MULTILINE

"पैरामीटर" के बीच अल्पविराम जोड़ने से मुझे लगता है कि यह वर्तमान वाक्यविन्यास के साथ थोड़ा और सुसंगत बना देगा:

export (String, MULTILINE) var my_var

पहला संस्करण थोड़ा और वर्बोज़ है, लेकिन मुझे लगता है कि यह इसे और अधिक स्पष्ट बनाता है और स्वत: पूर्ण के साथ इसे बहुत अधिक चोट नहीं पहुंचानी चाहिए :)

आगे चलकर और वाक्य रचना चर्चा होनी चाहिए। कुल मिलाकर मुझे यह विचार पसंद है।

एनोटेशन कॉन्फ़िगरेशन इंजेक्शन का एक अच्छा तरीका है। लेकिन कॉन्फ़िगरेशन और कोड को अलग करना IMO का अधिक स्वच्छ दृष्टिकोण हो सकता है। उन्हें जोड़ना हो सकता है जैसे हेडर फाइलें अधिक सहायक होती हैं।

@bojidar-bg की टिप्पणी से...

किसी भी मामले में, टिप्पणियों के एक वास्तविकता बनने से पहले काफी समय बीत जाएगा।

क्या कोई समझा सकता है कि "अवरुद्ध" मुद्दा क्या है जो इस कार्यान्वयन में देरी करेगा? क्या यह केवल GDScript / जनशक्ति से परिचित है, या क्या ऐसी विशिष्ट विशेषताएं हैं जिन्हें एनोटेशन का समर्थन करने के लिए समय से पहले लागू करने की आवश्यकता है?

खैर, मेरी टिप्पणी के बाद से काफी समय बीत चुका है, इसलिए मुझे लगता है कि यह पहले ही साबित हो चुका है?

एनोटेशन समर्थन के लिए मुख्य अवरोधक कोर डेवलपर्स को सिंटैक्स और शब्दार्थ पर सहमत होना होगा। बाद में, कार्यान्वयन अपेक्षाकृत आसान होना चाहिए।

हमें @reduz के साथ इस पर चर्चा करने की आवश्यकता है क्योंकि वह पसंद करते हैं कि एनोटेशन केवल मेटाडेटा के लिए हैं, उन्हें स्क्रिप्ट या संपादक के व्यवहार को प्रभावित नहीं करना चाहिए। इससे मेरा मूल प्रस्ताव बिलकुल व्यर्थ हो जाएगा।

मुझे अब भी लगता है कि एनोटेशन काफी स्पष्ट हैं, खासकर जब एकल कीवर्ड ( onready , master , puppet , आदि) को प्रतिस्थापित करते हैं। लेकिन हमें अभी भी आम सहमति तक पहुंचने की जरूरत है।

मुझे लगता है कि जैसा वर्णन किया गया है यह GDScript के लिए एक शानदार अतिरिक्त होगा। मुझे नहीं लगता कि यह मेटाडेटा तक सीमित होना चाहिए, यह निश्चित रूप से कई कीवर्ड से आगे निकल जाना चाहिए जो चर के लिए उपयोग किए जाते हैं, विशेष रूप से export जो कुछ मामलों में पढ़ने में थोड़ा कठिन हो सकता है; मुझे लगता है कि इसे कई बयानों में विभाजित करने से समझ में मदद मिलती है।

इसका उपयोग उस 3 साल पुराने अंक #6204 को सुरुचिपूर्ण ढंग से हल करने के लिए भी किया जा सकता है:

<strong i="8">@export</strong>
<strong i="9">@export_tooltip</strong> "The name used when displaying this item in the inventory and in shops."
var display_name := ""

मैं यह भी मानता हूं कि उन्हें केवल मेटाडेटा से अधिक समर्थन करना चाहिए। यह बहुत सारे तर्क को सरल करेगा और पठनीयता imo में सुधार करेगा।

मैं @willnationsdev से सहमत

@connect("timeout")
func _on_Timer_timeout():
   ...

@rluders यह मानते हुए कि स्क्रिप्ट Timer नोड पर है, हो सकता है।

@Zylann बिल्कुल। बस एक साधारण उदाहरण। यह "लक्ष्य" मापदंडों का समर्थन कर सकता है और इसे स्वयं-कनेक्ट करने के लिए छोड़ सकता है। उदाहरण के लिए, यदि स्क्रिप्ट Timer बाहर चल रही है:

@connect("timeout", $Timer)
func _on_Timer_timeout():
  ...

मुझे नहीं पता कि इसे कैसे लागू किया जा सकता है, लेकिन मैं वास्तव में जीडीएस में एनोटेशन देखना पसंद करूंगा, खासकर कीवर्ड के लिए। और रिकॉर्ड के लिए, मैं इसे पसंद करूंगा यदि एनोटेशन को अलग करने के लिए अर्धविराम या न्यूलाइन के बजाय '()' का उपयोग किया जाता है।

यह और भी बेहतर होगा यदि हम अपने स्वयं के एनोटेशन + पूर्ण विकसित एनोटेशन प्रोसेसर बना सकें।

@Zylann बिल्कुल। बस एक साधारण उदाहरण। यह "लक्ष्य" मापदंडों का समर्थन कर सकता है और इसे स्वयं-कनेक्ट करने के लिए छोड़ सकता है। उदाहरण के लिए, यदि स्क्रिप्ट Timer बाहर चल रही है:

@connect("timeout", $Timer)
func _on_Timer_timeout():
  ...

यह किसी तरह से एक प्लगइन द्वारा समर्थित हो सकता है, मैं इसे एक मुख्य विशेषता नहीं बनाऊंगा।
प्लगइन्स और भी अधिक शक्तिशाली हो सकते हैं।

मैं केवल इतना कह सकता हूं कि मुझे खुशी है कि मैंने इन चीजों को लागू करने से पहले जीडीस्क्रिप्ट सीखा क्योंकि

@export_hint(ENUM)
@export_hint_string("Attack,Defense")
export var my_enum : int = 0

एक नौसिखिया के रूप में मेरे लिए विश्लेषण करना बहुत कठिन और कठिन होता

@sleepcircle हम सभी मामलों में GDScript को सरल रखने का प्रयास करेंगे। इसलिए, यहां व्यंग्यात्मक होने की कोई आवश्यकता नहीं है: आपके द्वारा उद्धृत कोड केवल एक प्रस्ताव था, न कि _the_ भविष्य का वाक्य-विन्यास।

मुझे खेद है, मैं व्यंग्यात्मक होने की कोशिश नहीं कर रहा था। मैं बस यह मान रहा था, क्योंकि अधिकांश लोगों ने इन परिवर्धन को स्वीकार किया था, कि वे अपरिहार्य थे।

बस एक गेम देव प्रशिक्षक के रूप में अपना $0.02 फेंकना चाहता था। चेतावनी: अनावश्यक रूप से लंबी टिप्पणी जो ज्यादा योगदान नहीं देती है, सिर्फ 5 साल के लिए प्रोग्रामिंग सिखाने से मेरा अनुभव है कि नए डेवलपर्स इसे कैसे समझेंगे।

मुझे लगता है कि एनोटेशन जैसे नए भाषा मुहावरों के साथ आते समय यह महत्वपूर्ण है कि आपको हर वहन करने में मदद करनी चाहिए जो आप कर सकते हैं। उदाहरण के लिए connect , यह अब अच्छी तरह से काम करता है क्योंकि यह एक नए डेवलपर के लिए समझ में आता है कि आप एक ऐसे फ़ंक्शन को कॉल करते हैं जो पैरामीटर लेता है और इसके कुछ दुष्प्रभाव होते हैं।

यदि @ का उपयोग विशेष रूप से मेटाडेटा के लिए किया गया था, तो जब भी कोई नया डेवलपर @ देखता है तो वे इसे मेटाडेटा के रूप में पहचानते हैं जो उनके कोड तर्क को प्रभावित नहीं करता है। यदि यह तर्क को प्रभावित करता है, तो यह महत्वपूर्ण है कि हम नए मुहावरे नहीं जोड़ रहे हैं जो कभी-कभी x के रूप में उपयोग किए जाते हैं और कभी-कभी y के रूप में उपयोग किए जाते हैं।

अभी, एक चर को संशोधित करने के लिए, var उपसर्ग, प्रत्यय और विकल्प हैं। कुछ चीजें हैं जो मैं सूचीबद्ध करूंगा जो जरूरी नहीं कि "परिवर्तनीय संशोधक" हों, लेकिन नए डेवलपर्स उन्हें इस तरह देख सकते हैं

• उपसर्ग: onready , export(...)
  
  
  
  • इनमें से प्रत्येक का एक अलग प्रकार का व्यवहार होता है। onready रनटाइम वैरिएबल लोडिंग को प्रभावित करता है, export एक तरह का एडिटर हिंट/मेटाडेटा है। उन्हें एक ही स्थान पर उपयोग करने से ऐसा लगता है कि उनके व्यवहार को किसी तरह जोड़ा जाना चाहिए, जबकि वास्तव में ऐसा नहीं है
  
  
• विकल्प: class_name , extends , signal , enum , const , func
  
  
  
  • ये वैकल्पिक प्रारूप ठीक लगते हैं, लेकिन "एनम" और "कॉन्स्ट" को कहने, इनट्स या स्ट्रिंग्स से अलग करना एक अजीब पसंद की तरह लगता है
  
  
• प्रत्यय: setget
  
  
  
  • अपनी श्रेणी में सेटगेट ठीक है, लेकिन यह export है जिसमें यह डेवलपर्स के लिए एक चीनी कीवर्ड है और इतना तर्क बदलाव नहीं है। हालांकि, मैं यहां लोगों को अलग-अलग राय रखते हुए देख सकता हूं
  
  
• बीच में कहीं: var x : int = 5 टाइप करना
  
  
  
  • यह बीच-बीच में टाइपिंग अजीब लगती है, खासकर जब "एनम" और "कॉन्स्ट" एक ही चीज़ का प्रतिनिधित्व करने के लिए var के वैकल्पिक कीवर्ड हैं। निश्चित रूप से एक तर्क है कि const सेटगेट के समान है जिसमें यह गेम लॉजिक के लिए एक उपकरण की तुलना में डेवलपर के अनुभव को और अधिक संशोधित करता है।
  
  

तो अब आइए एनोटेशन के जोड़ को देखें।

एनोटेशन एक बिल्कुल नई अवधारणा/मुहावरा होगा जिसे नए डेवलपर्स को सिखाने की आवश्यकता होगी। आदर्श रूप से, नए डेवलपर्स को गति प्राप्त करने और चीजों को यथासंभव कुछ मुहावरों को जानने में सक्षम होना चाहिए ताकि वे नए मुहावरों को व्यवस्थित रूप से उठा सकें क्योंकि वे उनके लिए उपयोगी हो जाते हैं। इसे टेक-ट्री की तरह समझें।

• (टियर 1) वे केवल func, var, और कुछ बुनियादी प्रोग्रामिंग अवधारणाओं जैसे फ़ंक्शन कॉल, सशर्त और लूप को जानकर एक गेम बना सकते हैं
• (टियर 2) फिर वे उपयोगी चीनी/कार्यक्षमता सीखने के लिए आगे बढ़ते हैं, जैसे सिग्नल, कॉन्स्ट, एनम
• (टियर 3) वे शॉर्टकट सीखते हैं, जैसे सेटगेट, पहले से ही
• (टियर 3.1) वे केवल डेवलपर चीनी सीखते हैं, जो उनके खेल को नहीं बदलेगा, लेकिन निर्यात, संपादक विवरण, टूल और टाइपिंग जैसी चीजों के साथ उनकी प्रक्रिया को बदल देगा।
• (टियर 4) विशुद्ध रूप से प्रलेखन और परियोजना संरचना

मुझे लगता है कि टियर 3-4 टिप्पणियों के लिए प्रमुख लक्ष्य हैं। दो अलग-अलग कार्यान्वयन के लिए मैं अपने छात्रों को दो लिफ्ट पिच दूंगा:

• विशुद्ध रूप से मेटाडेटा: "अपने दस्तावेज़ीकरण और सहयोग में सहायता के लिए, अपनी स्क्रिप्ट में कुछ मेटाडेटा जोड़ने के लिए एनोटेशन के बारे में जानें। वे केवल टिप्पणियों का उपयोग करने से अधिक शक्तिशाली हैं।"
• देव शॉर्टहैंड/शुगर: "यदि आप अपने कोड को कम करना चाहते हैं या इसे अधिक पठनीय बनाना चाहते हैं, तो एनोटेशन पर एक नज़र डालें। वे आपको कुछ संपादक उपकरण और शॉर्टकट प्रदान करते हुए चर और कार्यों का वर्णन करने देते हैं।"

मैंने कई देवों को गोडोट सिखाया है, और मुझे लगता है कि एनोटेशन कम से कम एक टीयर 3 विकल्प, और अधिक से अधिक टियर 4 बनाना है। मुझे उन्हें @ प्रतीक नहीं दिखाना होगा जब तक कि वे पहले से ही न हों संपूर्ण, यथोचित रूप से जटिल खेलों का निर्माण कर रहे हैं और अपनी प्रक्रिया में सुधार करना चाहते

इसका मतलब है कि मेरी राय विशेष रूप से देव शॉर्टहैंड के लिए एनोटेशन का उपयोग करती है जो गेम कार्यक्षमता के लिए महत्वपूर्ण नहीं हैं/वैकल्पिक कार्यान्वयन या पूरी तरह से दस्तावेज़ीकरण के लिए महत्वपूर्ण हैं, क्योंकि लोगों को यह बताना आसान है कि "एक बार जब आप बड़ी परियोजनाओं का निर्माण कर रहे हों तो दस्तावेज़ीकरण की आवश्यकता होती है"।

धागे से विशिष्ट बिंदु:

• उन्हें निर्यात के लिए बिल्कुल सही होना चाहिए, क्योंकि निर्यात किसी भी खेल के लिए महत्वपूर्ण नहीं हैं
• पहले से ही एक आसान शॉर्टकट है, लेकिन आवश्यक नहीं है क्योंकि नए देव _ready में शुरुआत करके शुरू कर सकते हैं और नेस्टेड एनोटेशन की संभावना का अर्थ है onready कम बार लिखना
• सेटगेट पहले से ही ऐसा अजीब वाक्यविन्यास है, और पहले से ही इसका अपना मुहावरा एकमात्र प्रत्यय के रूप में है, कि यह पूरी तरह से वहां हो सकता है
• कनेक्ट: जैसा कि मैं आगे बढ़ता हूं, यह फ़ंक्शन कॉल मुहावरे के साथ पहले से ही सही है। कनेक्ट करने के कई तरीके होने से ट्यूटोरियल/नमूना कोड स्थान भ्रमित हो सकता है। शायद लोगों को अपने स्वयं के एनोटेशन लिखने की अनुमति देना इसे मानकीकृत करने से बेहतर होगा, ताकि बंद परियोजनाओं पर काम करने वाले देव एनोटेशन की एक लाइब्रेरी का निर्माण कर सकें जो जरूरी नहीं कि सार्वजनिक स्थान को भंग कर दे
• प्रकार: प्रकार अभी एक अजीब जगह पर हैं, जहां कुछ प्रकार के संशोधक विकल्प हैं और कुछ प्रकार के संशोधक बीच में हैं। हो सकता है कि उन्हें एनोटेशन के रूप में काम करना: @type(const int) @type(enum) , जो उन सभी को एक डेवलपर-उन्मुख चीनी के रूप में एकीकृत करेगा

फिर, एक बड़ा योगदान नहीं, लेकिन भोजन के लिए विचार जब यह सोचते हैं कि एनोटेशन के तहत किस कार्यक्षमता को कंबल दिया जाना चाहिए। मुझे लगता है कि वे एक महान विचार हैं, लेकिन यह स्पष्ट नहीं है कि वे कहाँ फिट होते हैं। लंबाई के लिए क्षमा करें, मैं हमेशा थोड़ा बहुत वर्बोज़ हूं।

मुझे यह नापसंद है।
मैं हर क्षेत्र, संपत्ति और विधि के लिए एनोटेशन का एक गुच्छा नहीं रखना चाहता

मेरे पास और कीवर्ड होंगे

अगर लोगों को ढेर सारे कीवर्ड पसंद नहीं आते हैं तो हम उनमें से कुछ को हटा सकते हैं

export MyClass : Node2D # export replaces class_name, : replaces extends 

signal mySignal #signal is kept

group(MyHeader, "res://icon.png" )
export var my_property : Array(int) setget _set_my_property, _get_my_property # : replaces export type

var test = 0 # no need for onready. variables declared outside of _ready automatically try to be onready vars

#others are kept

मैं मूल प्रस्ताव से पूरी तरह सहमत हूं।

मैं उपरोक्त टिप्पणियों से असहमत नहीं हूं, लेकिन पेशेवरों ने विपक्ष को गंभीर रूप से पछाड़ दिया है।

@Shadowblitz16 इनमें से कई सुझाव निम्नलिखित कारणों से यहां के लोगों को भ्रमित कर रहे हैं ...

export MyClass : Node2D # export replaces class_name, : replaces extends

export , class_name , : , और extends प्रत्येक 4 पूरी तरह से अलग डेटा बिंदुओं और प्रणालियों को कॉन्फ़िगर करता है। आप अन्य चीजों को अपरिवर्तनीय रूप से प्रभावित किए बिना उन्हें आसानी से इधर-उधर नहीं कर सकते।

• export जेनरेट की गई PropertyInfo ऑब्जेक्ट को कॉन्फ़िगर करता है जिसे संपादक GUI बनाने के लिए इंस्पेक्टर को भेजा जाता है।
• class_name ScriptServer में एक वैश्विक वर्ग के रूप में स्क्रिप्ट को पंजीकृत करता है। इसका तकनीकी रूप से टाइप सिस्टम से कोई लेना-देना नहीं है। यह केवल GDScript के "स्थिर टाइपिंग" का हिस्सा है क्योंकि यह रन-टाइम के बजाय पार्स-टाइम पर स्क्रिप्ट का वैश्विक उदाहरण बनाने के लिए होता है।
• वैकल्पिक प्रकार के संकेतों के लिए : का उपयोग किया जाता है। जब तक आप लोगों को हर समय स्थिर रूप से टाइप किए गए GDScript को बनाने और/या वैकल्पिक प्रकार के संकेत सिंटैक्स का प्रस्ताव करने के लिए राजी नहीं करते, तब तक कोलन टोकन का पुन: उपयोग करने का कोई तरीका नहीं है।
• extends का उपयोग विरासत में मिले वर्ग के लिए किया जाता है (जैसा कि आप जानते हैं)। यह अन्य भाषाओं में एक बहुत ही सामान्य वाक्यविन्यास है, और सभी दस्तावेज और ट्यूटोरियल पहले से ही इस पद्धति का पालन करते हैं। इससे दूर जाने और विशुद्ध रूप से एक कॉस्मेटिक कारण के लिए अधिक काम करने के लिए एक मजबूत प्रोत्साहन नहीं होने वाला है।

group(MyHeader, "res://icon.png")

यह मेरे लिए स्पष्ट नहीं है कि यह क्या करेगा। मेरा मतलब है, ऐसा लगता है कि नोड को "माईहेडर" समूह में जोड़ा जाएगा (जो समझ में आ सकता है), लेकिन आइकन किस लिए है? समूहों में उनके साथ जुड़े चिह्न नहीं होते हैं।

export var my_property : Array(int) setget _set_my_property, _get_my_property # : replaces export type

जैसा कि पहले कहा गया है, ये सभी चीजें अलग-अलग प्रणालियों को प्रभावित करती हैं, एक ही प्रणाली को नहीं। इसके अलावा, कई बार ऐसा भी हो सकता है कि आप किसी मान के प्रकार या उसके आरंभीकरण को लचीला बनाना चाहते हैं। उदाहरण के लिए, डायनेमिक GDScript में, आप कुछ इस तरह कर सकते हैं:

onready export(NodePath) var the_node = get_node(the_node)

var test = 0 # no need for onready. variables declared outside of _ready automatically try to be onready vars

तैयार अधिसूचना से पहले डेटा प्रारंभ करना समझ में नहीं आता है। स्क्रिप्ट ऑब्जेक्ट क्लास से जुड़ी हैं, नोड क्लास से नहीं। निर्माण के दौरान स्क्रिप्ट गुणों को आरंभीकृत किया जाता है। जब आप नोड क्लास के कंस्ट्रक्टर के पास जाते हैं तब भी यह नहीं बदलता है। _ready() अधिसूचना तत्काल के बाद बहुत बाद में होती है। ऑब्जेक्ट्स और नोड्स के बीच वैरिएबल इनिशियलाइज़ेशन का डिफ़ॉल्ट समय अलग-अलग होना बेहद भ्रमित करने वाला होगा और गोडोट को सीखने और उपयोग करने वालों के लिए बहुत सारे अप्रत्याशित व्यवहार का कारण बनेगा।

मेरा मतलब आपके सुझावों को कम करना नहीं है, बल्कि यह बताना है कि लोग इन सुझाए गए परिवर्तनों का औचित्य क्यों नहीं देख रहे हैं।

@willnationsdev ठीक है मैं समझता हूँ
एनोटेशन और अतिरिक्त कीवर्ड दोनों करने के बारे में क्या?
इस प्रकार यदि उपयोगकर्ता चाहें तो एनोटेशन का उपयोग कर सकते हैं और यदि वे प्रति फ़ील्ड दर्जनों एनोटेशन नहीं चाहते हैं तो कीवर्ड का उपयोग कर सकते हैं

संपादित करें: सी # को विशेषताओं के रूप में नोट करें जो आपको उन्हें इस तरह गठबंधन करने की अनुमति देता है ..
[Attribute1(), Attribute2()]
हालांकि यह लाइन गिनती को कम करने में मदद कर सकता है, फिर भी यह थोड़ा बदसूरत है

@ शैडोब्लिट्ज 16 जब संभव हो तो हम चीजों को करने का केवल एक ही स्पष्ट तरीका पसंद करेंगे। दो अलग-अलग वाक्य रचनाएँ होना उस लक्ष्य के विपरीत होगा।

@Calinou मुझे लगता है कि अगर लोग समझौता नहीं कर सकते हैं तो जीडीस्क्रिप्ट को छोड़ दिया जाना चाहिए।
1 - यह अनावश्यक रूप से पश्चगामी संगतता को तोड़ता है
2 - यह बड़ी फ़ाइलें और कम पठनीय कोड बनाता है
3 - यह लोगों को एक नई प्रणाली में बदलने के लिए मजबूर करता है जिसके वे अभ्यस्त नहीं हैं।
4 - यह लोगों को एक ऐसी प्रणाली का उपयोग करने के लिए मजबूर करता है जिसे वे शायद नहीं चाहते

1 - यह अनावश्यक रूप से पश्चगामी संगतता को तोड़ता है
2 - यह बड़ी फ़ाइलें और कम पठनीय कोड बनाता है
3 - यह लोगों को एक नई प्रणाली में बदलने के लिए मजबूर करता है जिसके वे अभ्यस्त नहीं हैं।
4 - यह लोगों को एक ऐसी प्रणाली का उपयोग करने के लिए मजबूर करता है जिसे वे शायद नहीं चाहते

ईमानदारी से, वे काफी खराब तर्क हैं। उन 4 में से 3 अंक एपीआई में किसी भी बड़े बदलाव के लिए निहित हैं, और उनमें से पहले को कुछ समय के लिए पुराने कीवर्ड-आधारित सिस्टम के साथ संगतता बनाकर काम किया जा सकता है (संभावित रूप से एक बहिष्करण चेतावनी के साथ)।

_संपादित करें: मुझे लगता है कि हम एक स्वचालित रूपांतरण उपकरण भी प्रदान कर सकते हैं।

बिंदु 2 के लिए, जबकि मुझे लगता है कि हर कोई इस तथ्य पर सहमत होगा कि एनोटेशन से अधिक लाइनों वाली फाइलें हो सकती हैं, यहां अधिकांश लोग इस तथ्य से असहमत हैं कि यह कम पठनीय कोड बनाता है।

@ यह अनावश्यक चीजों के लिए एनोटेशन का उपयोग कर रहा है
1 - हमें काम करने वाली किसी चीज़ को बहिष्कृत करने की आवश्यकता क्यों है?
2 - यह कम पठनीय है यदि आपको किसी फ़ील्ड को देखने के लिए 5 पंक्तियों को नीचे स्क्रॉल करना है

• निर्यात मूल रूप से संपादक के लिए एक सार्वजनिक कीवर्ड है
• स्क्रिप्ट चलने से पहले पहले से ही मूल रूप से एक var घोषणा है

दोनों एनोटेशन होने के लिए उपयुक्त नहीं हैं

सदस्य परिभाषाएं ही एकमात्र ऐसी चीज है जिसे मैं वास्तव में देख सकता हूं कि यह अच्छा है और उन्हें इस मामले में बंधने योग्य होना होगा, वे नहीं हैं।

@ यह अनावश्यक चीजों के लिए एनोटेशन का उपयोग कर रहा है

इस धागे में बहुत सारे उपयोग के मामले प्रस्तुत किए गए हैं। चाहे वह दस्तावेज़ीकरण, आत्मनिरीक्षण, अधिक जटिल प्लगइन्स के लिए हो ... एनोटेशन के लिए बहुत सारे उपयोग के मामले हैं जिन्हें कीवर्ड द्वारा कवर नहीं किया जा सकता है।

1 - हमें काम करने वाली किसी चीज़ को बहिष्कृत करने की आवश्यकता क्यों है?

ऐसा कुछ करने के बहुत सारे कारण हैं। क्लीनर एपीआई, अधिक लचीलेपन, आदि की अनुमति देने के लिए किसी भी सुविधा को विकसित करने की आवश्यकता हो सकती है ... और एक बार एक नए संस्करण का व्यापक रूप से उपयोग किया जाता है, जब संभव हो तो पिछले संस्करण के साथ संगतता को हटाना बेहतर होता है, क्योंकि इसमें निश्चित रूप से रखरखाव लागत होती है।

2 - यह कम पठनीय है यदि आपको किसी फ़ील्ड को देखने के लिए 5 पंक्तियों को नीचे स्क्रॉल करना है

अतिशयोक्ति करने की आवश्यकता नहीं है। इस तरह के प्रस्ताव पर चर्चा करने का लक्ष्य ऐसी समस्याओं से बचने के लिए सिंटैक्स को पर्याप्त स्मार्ट बनाना है। आईएमएचओ, निर्यात संकेतों को निर्यात एनोटेशन के तर्क के रूप में एकीकृत किया जा सकता है (बशर्ते हमारे पास एक नामित तर्क प्रणाली हो जो मुझे लगता है)। ऐसी स्थितियों में, सिस्टम पहले से भी कम जगह ले सकता है।

साथ ही, हम यह भी कल्पना कर सकते हैं कि एनोटेशन फ़ील्ड के समान ही हों। मुझे नहीं लगता कि इससे कोई समस्या हो सकती है।

निर्यात मूल रूप से संपादक के लिए एक सार्वजनिक कीवर्ड है
स्क्रिप्ट चलने से पहले पहले से ही मूल रूप से एक var घोषणा है
दोनों एनोटेशन होने के लिए उपयुक्त नहीं हैं

ठीक है, आपने संभवतः पूर्वकल्पित विचार रखे होंगे कि एनोटेशन किस लिए हैं। मुझे लगता है कि वे केस केस पूरी तरह से एक एनोटेशन सिस्टम में फिट होते हैं (और ऐसा लगता है कि बहुत से लोग करते हैं)। लेकिन वास्तव में, मुझे लगता है कि प्रत्येक स्थिति पर केस दर केस चर्चा की जानी चाहिए।

मुझे "लाइन्स" तर्क विशेष रूप से अच्छा नहीं दिख रहा है। भले ही एनोटेशन सीधे तौर पर प्रति पंक्ति (या एक "उपसर्ग" फ़ॉर्म) एकाधिक कथनों की अनुमति नहीं देते हैं, फिर भी आप ; को एक सीमांकक के रूप में उपयोग कर सकते हैं।

<strong i="7">@onready</strong> var my_sprite = $Sprite
@onready; var my_sprite = $Sprite


@export_hint_string("Attack,Defense")
@export_hint(ENUM) export var my_enum : int = 0

@export_hint_string("Attack,Defense")
@export_hint(ENUM); export var my_enum : int = 0


<strong i="8">@export_hint_string</strong> "Attack,Defense";
<strong i="9">@export_hint</strong> ENUM export var my_enum : int = 0

<strong i="10">@export_hint_string</strong> "Attack,Defense"
<strong i="11">@export_hint</strong> ENUM; export var my_enum : int = 0


<strong i="12">@export</strong> type=String hint=MULTILINE; var my_text = ""

# more options

@export(type = String, hint = MULTILINE) var my_text = ""
@export(type = String, hint = MULTILINE); var my_text = ""

@export(String, hint = MULTILINE) var my_text = ""

# I personally prefer this one (positional and named args supported, default/optional args too)
@export(String, MULTILINE) var my_text = ""
@export(String, hint = MULTILINE) var my_text = ""
@export(type = String, hint = MULTILINE) var my_text = ""
@export(int, ENUM, "Attack,Defense") var my_enum:= 0

संपादित करें: ओह, मैं बहुत धीमा था, @groud ने पहले ही लाइन तर्क को संबोधित किया था। खैर, कम से कम उन कुछ कोड उदाहरणों ने इस धागे में कुछ जोड़ा।

यह आप लोगों की राय है।
मुझे व्यक्तिगत रूप से लगता है कि @ बदसूरत है

संपादित करें:
तो सदस्य घोषणा कैसे काम करेगी?
ऐसा करना भयानक होगा

<strong i="10">@description</strong> "Adds two numbers and returns the result."
<strong i="11">@parameter</strong> name=num1 type=float description="The first number"
<strong i="12">@parameter</strong> name=num2 type=float description="The second number"
<strong i="13">@returns</strong> type=float description="num1 and num2 added together"
func add(num1, num2):
    return num1 + num2

जब तक यह @description की शुरुआत से func की शुरुआत तक ढहने में सक्षम नहीं था

मेरा मानना ​​​​है कि एनोटेशन प्रकारों को बदलने के लिए नहीं हैं (जैसा कि आपका उदाहरण ऐसा लगता है)। यदि आप दस्तावेज़ीकरण एनोटेशन नहीं चाहते हैं, तो आपको उनका उपयोग करने के लिए बाध्य नहीं किया जाएगा:

func add(num1: float, num2: float) -> float: return num1 + num2

यह भ्रम शायद निर्यात संकेतों के साथ आदर्श स्थिति से कम से उत्पन्न होता है, जहां तक ​​​​मुझे पता है, आप वास्तविक प्रकारों का उपयोग नहीं कर सकते हैं (और सामान्य प्रकार नहीं होने की समस्या जो आश्चर्यजनक रूप से कुछ प्रकारों जैसे सरणी के लिए संकेतों का समर्थन करती है)।

मुझे व्यक्तिगत रूप से लगता है कि @ बदसूरत है
तो सदस्य घोषणा कैसे काम करेगी?
ऐसा करना भयानक होगा

अन्य भाषाओं में यह उद्देश्य आम तौर पर टिप्पणियों की सेवा करता है, एनोटेशन नहीं और आमतौर पर जो सुझाव दिया गया था उससे बराबर या अधिक वर्बोज़ पर होता है। एक सी भाषा परिवार (सबसे लोकप्रिय भाषाओं) में @ एनोटेशन के लिए बहुत आम है (उदाहरण के लिए जावा, जावास्क्रिप्ट, टाइपस्क्रिप्ट, स्कैला और जो मैंने पाइथन भी पढ़ा है)।

टाइपस्क्रिप्ट (मेरा मानना ​​​​है कि डॉक्स में प्रकारों की आवश्यकता नहीं है और उपकरण वास्तविक प्रकारों का उपयोग कर सकते हैं):

/** Adds two numbers and returns the result.
 * <strong i="16">@param</strong> num1 {float} The first number
 * <strong i="17">@param</strong> num2 {float} The second number
 * <strong i="18">@return</strong> {float} num1 and num2 added together
  **/
const add = (num1: number, num2: number): number => num1 + num2;

फंक जैसा स्वाद:

@description("Adds two numbers and returns the result.")
@parameter(num1, "The first number", type=float)
@parameter(num2, "The second number", type=float)
@returns("num1 and num2 added together", type=float)
func add(num1: float, num2: float) -> float:
    return num1 + num2

डुप्लिकेट प्रकारों के बिना:

@description("Adds two numbers and returns the result.")
@parameter(num1, "The first number")
@parameter(num2, "The second number")
@returns("num1 and num2 added together")
func add(num1: float, num2: float) -> float:
    return num1 + num2

माता-पिता रहित स्वाद:

<strong i="28">@description</strong> "Adds two numbers and returns the result."
<strong i="29">@parameter</strong> num1 "The first number"
<strong i="30">@parameter</strong> num2 "The second number"
<strong i="31">@returns</strong> "num1 and num2 added together"
func add(num1: float, num2: float) -> float:
    return num1 + num2

मुझे यह सिंटैक्स डॉक्टर टिप्पणियों के लिए सबसे अच्छा लगता है। मैं अभी भी प्रलेखन उद्देश्यों के लिए एनोटेशन का उपयोग करने के बारे में आश्वस्त नहीं हूं, क्योंकि गैर-डॉक्टर एनोटेशन के लिए मैं func- जैसे सिंटैक्स पसंद करूंगा।

मैंने पिछले उदाहरण से एनोटेशन नामों का उपयोग किया, @parameter अन्य भाषाओं की तरह केवल @param @description हो सकता है, @desc , @descr या @func ।

गोडोडॉक में मैं टाइपस्क्रिप्ट (टाइपडॉक जो स्वयं जेएसडॉक और जावाडोक पर आधारित है) पर आधारित सिंटैक्स का उपयोग कर रहा हूं और, मेरी राय में, यह काफी अच्छी तरह से काम करता प्रतीत होता है:

## Same as [[bool_]], but `on_false`/`on_true` are functions.
## Only selected function will be called and its return value will be returned from `bool_lazy`.
## <strong i="44">@typeparam</strong> T {any} Return type
## <strong i="45">@param</strong> cond {bool} Condition
## <strong i="46">@param</strong> on_false {FuncLike<T>} Function to call and return its result when `cond` is `false`
## <strong i="47">@param</strong> on_true {FuncLike<T>} Function to call and return its result when `cond` is `true`
## <strong i="48">@return</strong> {T}
func bool_lazy_(cond: bool, on_false, on_true): return GGI.bool_lazy_(cond, on_false, on_true)
var bool_lazy = funcref(self, "bool_lazy_")

जब तक कि यह @description की शुरुआत से func . की शुरुआत तक ढहने में सक्षम नहीं था

हां, आम तौर पर फोल्डिंग और डिफ़ॉल्ट फोल्डिंग के लिए एक विकल्प संपादक के लिए एक अच्छा जोड़ा होगा (एक प्रकार के ब्लॉक के आधार पर फोल्डिंग, उदाहरण के लिए आप सेटिंग्स में सक्षम कर सकते हैं कि आंतरिक कक्षाएं डिफ़ॉल्ट रूप से ध्वस्त हो जाएंगी)।

मुझे एनोटेशन को सामने या ऊपर रखने की क्षमता पसंद है, इसके लिए @annotation(a, b) अच्छा है, यदि कोई पैरा नहीं दिया गया है तो ब्रैकेट वैकल्पिक हैं। सामने रखने में सक्षम होने के कारण आज के कीवर्ड के रूप में लेखन की समान गति की अनुमति मिलती है, क्योंकि export और onready गुणों के साथ बहुत आम हैं।

हालाँकि उपयोग के मामले में, मैं दस्तावेज़ीकरण को भी नापसंद करता हूँ। मुझे कार्यक्रम पर प्रभाव डालने वाली टिप्पणियों के लिए उपयोग किया जाता है (भले ही अप्रत्यक्ष रूप से), जबकि दस्तावेज़ीकरण अक्सर टिप्पणी-जैसे उपयोग के लिए उनकी राशि को तीन गुना कर देगा, फिर हर जगह दिखाई देगा और कार्यात्मक एनोटेशन के समान ही हाइलाइट किया जाएगा ... यह कुछ के लिए उपयुक्त नहीं है वह सर्वव्यापी। मूल रूप से, मुझे एनोटेशन का वही उपयोग पसंद है जो सी # में पाया जा सकता है, जिससे सदस्यों के शीर्ष पर बहुत कम एनोटेशन लिखे जाते हैं (वे आमतौर पर बहुत दुर्लभ होते हैं, हर किसी को 5 लाइनें नहीं लिखनी पड़ती हैं जैसा कि कुछ उदाहरणों में दिखाया गया है) . यदि तर्क गोडोट के पास स्क्रिप्ट दस्तावेज़ निर्दिष्ट करने के लिए कोई एपीआई नहीं है, तो यह समस्या है, केवल एनोटेशन आईएमओ के साथ हल नहीं किया जाना चाहिए। कम से कम, मुझे लगता है कि कोई वैकल्पिक रूप से इसका उपयोग कर सकता है, लेकिन मैं इसे इस तरह से करने के लिए मजबूर नहीं होना चाहता, जो मुझे पूर्ण पैमाने पर दस्तावेज़ीकरण के लिए असुविधाजनक लगता है। (इसके अलावा, स्क्रिप्ट केवल GDScript नहीं हैं, और _get_property_list का उपयोग करने का एज केस इसे और भी अजीब बनाता है)

मुझे लगता है कि मैं ज़िलान से पूरी तरह सहमत हूं। मैं व्यक्तिगत रूप से निर्यात (या पहले से) जैसे कीवर्ड के लिए ऐसे सिंटैक्स की अनुमति दूंगा:

# No parenthesis when there are no parameters
<strong i="6">@export</strong> var myvar
# With parenthesis for parameters
@export(ENUM, "Up,Down,Left,Right") var myvar2
# Being able to write the annoation on the line before
@export(ENUM, "Up,Down,Left,Right") 
var myvar2

प्रलेखन भाग के संबंध में, मैं वाक्यविन्यास को और भी सरल बना दूंगा ( हुए ):

<strong i="11">@description</strong> "Adds two numbers and returns the result."
<strong i="12">@parameter</strong> "The first number" # No need to name the args if they are ordered
<strong i="13">@parameter</strong> "The second number"
<strong i="14">@returns</strong> "num1 and num2 added together"
func add(num1: float, num2: float) -> float:
    return num1 + num2

हालांकि, मैं मानता हूं कि एक अन्य प्रणाली विकसित करना अनिवार्य है ताकि प्रलेखन कहीं और लिखा जा सके। एक जेसन, एक्सएमएल या आरएसटी फाइल में मैं कहूंगा। इन-कोड दस्तावेज़ीकरण हर प्रोजेक्ट में फिट नहीं होता है, और मैं सहमत हूं कि केवल दस्तावेज़ीकरण के लिए बहुत सारे एनोटेशन जोड़ना कष्टप्रद हो सकता है और कुछ मामलों में कोड को पढ़ने में कठिन बना सकता है।

प्रासंगिकता के लिए लिंकिंग: Godotengine/godot-proposals#177

पार्टी के लिए बहुत देर हो चुकी है, लेकिन देव के रूप में जो प्लगइन्स विकसित करने के लिए मेटाडेटा और प्रतिबिंब पर बहुत अधिक निर्भर करता है, मैं वास्तव में एनोटेशन को गोडोट में देखना पसंद करूंगा।

जबकि मुझे लगता है कि यह कुछ सामान को और अधिक सुंदर बनाता है (जैसे निर्यात और पहले से ही सामान) मेरा मुख्य तर्क कस्टम प्लगइन्स के लिए होगा जो एनोटेशन का पूर्ण विस्तार से उपयोग कर सकते हैं।

onready कीवर्ड और उसकी सीमाओं के संबंध में।

मुझे लगता है कि यह कहना सुरक्षित है कि ज्यादातर लोग onready का उपयोग नोड संदर्भों को जल्दी शुरू करने के लिए करते हैं। सिवाय इसके कि यह लंबे समय में मुद्दों के बिना संभव नहीं हो सकता है, क्योंकि जब आप कुछ दृश्यों का उदाहरण देते हैं जो _ready निर्भर हैं, तो आप null को संदर्भित करने के मुद्दे पर ठोकर खा सकते हैं:

func explode():
    var bomb = preload("res://explosion.tscn").instance()
    # Oops, forgot to `add_child(bomb)` earlier
    bomb.fuse.wait_time = 5.0 # ERROR: fuse is `null`
    add_child(bomb)
    # ... because `fuse` is a $Timer node 
    # which is only initialized once added to the scene tree.

निश्चित रूप से आपको add_child() को सेट करने का प्रयास करने से पहले इंस्टेंस्ड सीन की जरूरत है fuse , लेकिन क्या होगा अगर अन्य नोड्स/ऑब्जेक्ट्स को सीन ट्री में सीन जोड़ने से पहले सटीक फ्यूज के बारे में पता होना चाहिए ?

कुछ समय बाद मुझे https://github.com/godotengine/godot/issues/33620#issuecomment -559999681 में वर्णित समाधान मिल गया है। जैसा कि आप वहां देख सकते हैं, onready सिर्फ NOTIFICATION_READY , जबकि मुझे वास्तव में जो चाहिए वह NOTIFICATION_INSTANCED और मेरे संदर्भों को पहले भी प्रारंभ करना था। एकमात्र समस्या यह है कि कोई oninstanced कीवर्ड नहीं है, और मुझे लगता है कि आप समझ सकते हैं कि मैं किस ओर जा रहा हूं। मैं

इसलिए, मुझे लगता है कि onready कीवर्ड को एक एनोटेशन के रूप में रीमेक करना अच्छा होगा, जबकि कुछ अन्य कोने के मामलों का भी समर्थन करना (जैसे मेरा, हमेशा की तरह!) @oninstanced कार्यक्षमता के साथ स्क्रिप्टिंग भाषा को फूला हुआ बिना , साथ ही आरंभीकरण से संबंधित अन्य सूचनाओं के लिए समर्थन जोड़ना ( _init , _enter_tree , आदि)।

संबंधित प्रस्ताव: godotengine/godot-proposals#260.

अधिक विशिष्ट विवरण के साथ एक प्रस्ताव खोला: https://github.com/godotengine/godot-proposals/issues/828

उपरोक्त प्रस्ताव से विस्थापित।