Godot: GDScript में वैकल्पिक टाइपिंग

ऐसा लगता है कि आप कर सकते हैं

func myfunction(something = InputEvent):

और अगर वे कुछ भी पास नहीं करते हैं तो यह आपको एक खाली इनपुट ईवेंट देगा, लेकिन उस प्रकार के चर को लागू नहीं करता है

myfunction('string')

ठीक काम करेगा।

यह रोडमैप पर है :)
https://github.com/godotengine/roadmap/blob/master/ROADMAP.md

@Hinsbart
यह कैसा दिखाई दे सकता है या यह GDScript के अन्य भागों के साथ कैसे कार्य करेगा, इसका कोई संदर्भ? या यह रोड मैप पर सिर्फ एक विचार है?

दुर्भाग्य से नहीं, कुछ आईआरसी चर्चाओं के अलावा, इसके लिए अभी तक कोई संदर्भ नहीं है।

CC @reduz , इसके लिए उनके मन में कुछ संकेत देने के लिए।

@ लियोनार्डमेघेर 2 जैसा आपने लिखा है

व्हाट अबाउट:

func myfunction(something is InputEvent, something_else is String):

यह मेरे लिए बहुत अच्छा है, is कीवर्ड को अधिक उपयोगी बनाता है और कोड को समझने में आसान बनाता है

मैं असहमत हूं। मैं या तो String something या something : String साथ ठीक something is String मुझे बुरा लग रहा है।

String something या something is String दोनों मेरे लिए ठीक हैं। कोलन का उपयोग करने से मुझे लगता है कि कोड में बहुत सारे कोलन संकेत होंगे।

यदि is का उपयोग नहीं किया जाएगा तो मैं String something पसंद करूंगा क्योंकि मुझे अन्य भाषाओं से इस संकेतन की आदत है और मुझे लगता है कि यह अधिक सामान्य है।

@neikeq
यदि आप एक var बनाते समय भी प्रकार की घोषणा कर सकते हैं, जैसे var something:String = " " मैं सहमत हूँ

अन्यथा मुझे लगता है कि केवल कार्य परिभाषाओं में अर्धविराम का उपयोग करना अधिक भ्रमित होगा।

"Is" का उपयोग अब gdscript में इनहेरिटेंस के बारे में पूछने के लिए किया जाता है, तो इसकी आवश्यकता क्यों नहीं हो सकती है?

सी टाइप प्रीफिक्स बेहतर आईएमओ होगा। यह टाइप करने के लिए छोटा, तेज़ है और प्रकारों का उपयोग करते समय var या func को प्रतिस्थापित कर सकता है।

उदाहरण:

int some_variable

int some_function(int some_argument):
    return some_variable + some_argument

उस पर मेरा वोट।

@ जुआन-गार्सिया-एम
मुझे नहीं लगता कि यह किसी ऐसे व्यक्ति के लिए इसे और अधिक समझने योग्य बनाता है जो टाइपिंग की तरह सी से परिचित नहीं है। मुझे लगता है कि टाइप करना आसान हो सकता है, लेकिन बहुत कम पठनीय।
मैं एक नज़र में यह जानना पसंद करता हूं कि कोई फ़ंक्शन या चर क्या है, और उन कीवर्ड को प्रकारों से बदलने से मेरे लिए वह क्षमता समाप्त हो जाएगी; यह एक कारण है कि C और C++ में प्रवेश करना मेरे लिए कठिन है।

जाहिर है कि भाषा मेरे लिए नहीं बन सकती, लेकिन मुझे यकीन है कि मैं अकेला ऐसा नहीं हूं जो इस तरह महसूस करता है।

"है" के साथ एक समस्या, वर्तमान में इसका उपयोग 3.0 में "विस्तारित" होने के लिए किया जाता है, यानी यह जांचना कि कोई नोड कक्षा से संबंधित है या नहीं।

@Zireal07
इसलिए मुझे फ़ंक्शन घोषणा में प्रकार की जांच करना उचित लगता है।
विस्तार अभी भी वह स्क्रिप्ट के शीर्ष पर उपयोग किया जाता है, लेकिन प्रकार की जांच के लिए "है" का उपयोग किया जाता है (और मुझे लगता है कि अक्षर के लिए टाइपोफ)।

सी शैली उपसर्ग सामान्य रूप से अधिक जटिल है, और इस प्रकार की भाषाओं के लिए मानक परिवर्तनशील प्रतीत होता है: प्रकार सम्मेलन, ताकि इसका उपयोग किया जा सके

यह बंद क्यों किया गया? यह अभी भी लागू नहीं हुआ है ...

मैंने इसे बंद कर दिया क्योंकि यह सिर्फ एक चर्चा थी, लेकिन मैं वांछित फीचर की प्रगति को ट्रैक करने के लिए इसे फिर से खोलूंगा

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

var foo: String = 'bar'

... केवल var कीवर्ड को प्रकार से बदलने के बजाय...

String foo = 'bar'

...मुझे पागल बना दो। मुझे पता है कि यह बहुत छोटा और नीट-पिक्य लगता है, लेकिन एक गेम पर काम करने की लंबी अवधि में इसका परिणाम आवश्यक से अधिक कीस्ट्रोक के रूप में होता है।

यहां बताया गया है कि इसे कैसा दिखना चाहिए:

पायथन सिंटैक्स के बाद (टाइपस्क्रिप्ट और हैक्स के समान)।

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

एक और बिंदु प्रो पायथन तरीका है: इसे पार्स करना बहुत आसान है। इसे समायोजित करने के लिए वर्तमान पार्सर को ज्यादा बदलाव नहीं करना पड़ेगा। प्रीफ़िक्स्ड प्रकारों के लिए, यह तय करने के लिए कि क्या करना है, संदर्भ के बारे में अधिक सामग्री पर विचार करना होगा।

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

extends Node

const int MY_CONSTANT = 0
String my_member_variable = "Value"

void my_empty_func():
    pass

float my_other_func(bool arg1, Node2D arg2, bool default = false):
    Vector2 local_variable
    int other_variable = 0

    return float(other_variable)

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

वैसे भी, यह सिर्फ मेरे दो पैसे के लायक है: मुस्कान:। मैं अब तक जीडीस्क्रिप्ट में विकास का आनंद ले रहा हूं और मैं इसके लिए एक ध्वनि प्रकार प्रणाली की प्रतीक्षा कर रहा हूं।

पायथन पहले से ही इसका समर्थन करता है, इसलिए मुझे लगता है कि हम जो सबसे अच्छा कर सकते हैं वह है वहां से कॉपी करना

जो लोग var कीवर्ड से नफरत करते हैं, उनके लिए निम को सिंटैक्स की तरह जोड़ना संभव हो सकता है जो कुछ इस तरह की अनुमति देते हैं।

  a:int
  b:float
  c:char

const
  PI:float = 3.1416
  MAX:int = 100

मुझे आश्चर्य है कि वापसी प्रकारों की आवश्यकता क्यों है, यदि आप लौट रहे हैं और वह आउटपुट एक विशिष्ट प्रकार के चर के लिए जा रहा है और वे मेल नहीं खाते हैं, तो यह फेंक देगा।
मुझे लगता है कि आप अपना कोड चलाने से पहले संपादकों को आपके लिए उस गलती को खोजने की क्षमता प्राप्त करेंगे।

वापसी प्रकार void मुझे ज्यादा समझ में नहीं आता है, मुझे लगता है कि उस मामले में वापसी प्रकार परिभाषा को छोड़ना आसान होगा।

अंत में -> मुझे अजीब लगता है अगर हमारे पास रिटर्न प्रकार होने जा रहे थे, लेकिन मुझे लगता है कि आप कुछ निम-जैसे func somefunc(): String: (शायद?) उस तीर का प्रशंसक सिंटैक्स की तरह है क्योंकि यह भी मुझे बहुत कुछ इंगित नहीं करता है, दिशात्मक लगता है लेकिन इसका इससे कोई लेना-देना नहीं है, मुझे बिट-वार ऑप्स >> और << याद दिलाता है लेकिन वे एक तरह से दिशात्मक हैं।

__इस मुद्दे को बंद करने का मतलब नहीं था__

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

यह अब बहुत मायने नहीं रखता है, लेकिन लोग प्लगइन्स और यहां तक ​​​​कि गेम कोड भी लिख पाएंगे जो कि इसके काम करने के तरीके में बेहद गतिशील हो सकते हैं। आईई, एक प्लगइन में यह चेतावनी संदेश हो सकता है: "इस नोड को एक्स रिटर्न प्रकार के साथ एक फ़ंक्शन की आवश्यकता होती है, लेकिन जिस नोड को आप संदर्भित करने का प्रयास कर रहे हैं उसके पास आवश्यक विधि हस्ताक्षर नहीं है।"

मैंने एआई बिहेवियर नामक यूनिटी के लिए एक प्लगइन लिखा है जो उपयोगकर्ता मित्रता के लिए इस प्रकार के सामान (सिस्टम। रिफ्लेक्शन के माध्यम से) का काफी उपयोग करता है। मेरे पास सचमुच एक ड्रॉप डाउन मेनू है जिसे मैं उपलब्ध विधि नामों के साथ पॉप्युलेट करता हूं और उन्हें सही हस्ताक्षर वाले सभी तरीकों के आधार पर कॉलबैक के रूप में उपयोग करने के लिए किस विधि का उपयोग करना चाहता हूं, फिर जब गेम चलता है, तो वह विधि है जिसे नीचे बुलाया जाता है जिस परिस्थिति के लिए बनाया गया है। यदि उस ऑब्जेक्ट/स्क्रिप्ट पर कोई विधि मौजूद नहीं है जिस पर वे इसे एक्सेस करने का प्रयास कर रहे हैं तो यह इंस्पेक्टर में नमूना कोड दिखाएगा ताकि वे कोड को कॉपी/पेस्ट करके और कक्षा का नाम बदलकर एक स्क्रिप्ट बना सकें। :)

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

मुझे यह भी लगता है कि टाइपस्क्रिप्ट स्टाइल सिंटैक्स ( var name: String = "Godot" का उपयोग करके) बेहतर है क्योंकि यह गतिशील भाषाओं में जोड़े गए वैकल्पिक टाइपिंग के लिए कुछ हद तक मानक वाक्यविन्यास बन गया है।

साथ ही, पायथन सिंटैक्स का पालन करना एक अच्छा विचार है:
https://www.python.org/dev/peps/pep-0484/
https://docs.python.org/3/library/typing.html

यह वैकल्पिक टाइपिंग के साथ समान गतिशील भाषाओं से GDScript में आने वाले लोगों की सहायता करेगा।

बीटीडब्लू, कब/किस रिलीज में हम इसे लागू करने की उम्मीद कर सकते हैं? मैंने 3.1 का उल्लेख देखा है?

यह गोडोट 3.1 में उपलब्ध होना चाहिए।

सी शैली उपसर्ग के खिलाफ तर्कों के बारे में अधिक जटिल या कम समझने योग्य/पठनीय होने के बारे में और यह पाइथन वाक्यविन्यास या इसी तरह के साथ जाने के लिए और अधिक स्वागत योग्य है- क्या सभी डॉक्स उस सी शैली के उपसर्ग का उपयोग सभी विधियों के साथ नहीं कर रहे हैं और ऐसे? जैसे, कैमरा पेज से केवल एक को निकालने के लिए वास्तव में जल्दी set_orthogonal ( float size, float z_near, float z_far ) मैं इसे पहले खुद समझ नहीं पाया, लेकिन मुझे लगता है कि सीखने में केवल एक पल लगता है, और उसके बाद यह पूरी तरह से समझ में आता है।

नमस्ते, यहाँ प्रस्ताव।

तर्क:
मुझे लगता है कि हमें स्थिर टाइपिंग की आवश्यकता है, लेकिन यदि संभव हो तो मैं उपयोगकर्ता को प्रकार निर्दिष्ट करने के लिए मजबूर करने से बचूंगा।
सभी प्रमुख संकलित भाषाएं स्थिर प्रकार के अनुमान की ओर बढ़ रही हैं।
मुझे पता है कि @reduz वास्तव में गोडोट स्रोत कोड के लिए प्रकार का अनुमान पसंद नहीं करता है, और मैं इसे स्पष्टता के दृष्टिकोण से समझ सकता हूं। हालांकि मुझे लगता है कि यह समझौता जीडीस्क्रिप्ट के लिए वास्तव में अच्छी तरह से काम कर सकता है क्योंकि यह स्थिर प्रकार की जांच के अधिकांश फायदों के साथ कोडिंग गति में बाधा नहीं डालता है।
सुनिश्चित नहीं है कि कार्यान्वयन हालांकि अधिक जटिल है।
इसके लिए बीजीय डेटा प्रकारों के रूप में कुछ अतिरिक्त लागतों की आवश्यकता होगी।
यहाँ एक भाषा है जो इस सिद्धांत का उपयोग करती है

https://crystal-lang.org/docs/

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

इस प्रकार की प्रणाली क्या कर सकती है इसका एक उदाहरण यहां दिया गया है (उन लोगों के लिए जो थोड़ा सा रूबी जानते हैं)

def test(x)
    return true if x
    return "This is false"
end

puts test(false).upcase
puts test(true)

आउटपुट:

Error in test.cr:6: undefined method 'upcase' for Bool (compile-time type is (Bool | String))

puts test(false).upcase
                 ^~~~~~

विचार?

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

@ m4nu3lf का उदाहरण काफी दूर तक जाता है, यह वास्तव में ब्रांचिंग के आधार पर परिणामी प्रकार का @reduz GDScript के साथ कितनी दूर जाना चाहता है।

गौर करें कि गोडोट में काफी सख्त प्रकार की प्रणाली है, लेकिन सभी चर भिन्न हैं (यानी वे किसी भी प्रकार को स्टोर कर सकते हैं)। चूँकि यह अनुकूलता भंग करने के लिए नहीं है, उन्हें ऐसे ही रहना है। तो var value = 42 करना स्वचालित रूप से यह नहीं मानेगा कि चर एक पूर्णांक है, विशेष रूप से कक्षा-स्तर वाले लोगों के लिए जिन्हें बाहरी स्क्रिप्ट द्वारा इच्छानुसार सेट किया जा सकता है। यह एक गुच्छा में बाधा डालता है कि किस प्रकार का अनुमान किया जा सकता है (हालांकि इसे पूरा करने के उद्देश्यों के लिए इस तरह इस्तेमाल किया जा सकता है)।

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

@vnen सिद्धांत रूप में पैरामीटर/रिटर्न प्रकार/चर जैसे 'ऑटो' या 'लेट' के लिए कुछ नए कीवर्ड का उपयोग करके और क्रिस्टल-लैंग के समान एल्गोरिदम का उपयोग करके आप संकलन समय पर प्रकार का अनुमान लगाने में सक्षम हो सकते हैं।
यह पूर्ण प्रकार के अनुमान के साथ स्थिर टाइपिंग है।
मान लीजिए आपके पास है
auto my_field = 42 एक स्क्रिप्ट में आप केवल int होने का अनुमान लगा सकते हैं और अंतर्निहित संस्करण को केवल ints तक सीमित कर सकते हैं।

हालाँकि वह भाषा सरल चर से परे है। यह शाखाओं के आधार पर प्रकार को प्रकारों के सबसेट तक सीमित कर सकता है।
जैसे रिटर्न प्रकार के ऊपर के उदाहरण में केवल एक स्ट्रिंग या एक बूल हो सकता है।
लेकिन ऐसा करने के लिए आपको

• तर्क प्रकारों के प्रत्येक नए संयोजन के लिए तत्काल कार्य करें और प्रत्येक वापसी अभिव्यक्ति के लिए आंतरिक प्रकारों का अनुमान लगाएं, संभावित वापसी प्रकारों की सूची को वापसी मूल्य के प्रकार के रूप में सहेजें।
• शाखाओं के लिए एक निश्चित समय में सभी संभावित प्रकार के चर का अनुमान लगाने के लिए सभी संभावित शाखाओं को उजागर करें जहां एक चर को सौंपा गया है। किसी भी समय, प्रकार के प्रकार को उन तक सीमित रखें

इसके अलावा आपको "instof" शर्तों की जांच करनी चाहिए और जैसे in

if my_var instanceof MyClass:
...

तो आप जानते हैं कि अगर स्थिति के शरीर में my_var केवल 'MyClass' हो सकता है, तो प्रकार और भी प्रतिबंधित है।
इसके लिए किसी भी लाभ के लिए आपको केवल उन विधियों या एक्सेस फ़ील्ड को कॉल करने में सक्षम होना चाहिए जिनके नाम सभी संभावित प्रकारों में साझा किए गए हैं।
तो चलिए बताते हैं

auto x = MyClass.new()
if (...):
   x = "hi"

फिर इसके बाद x या तो MyClass या String होता है। रनटाइम त्रुटियों से बचने के लिए आप केवल उन विधियों को कॉल करने में सक्षम होंगे जो दोनों के लिए सामान्य हैं।

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

@ m4nu3lf मैं समझता हूं कि आपका अनुरोध क्या है, टाइपस्क्रिप्ट बहुत समान है (जो एक ऐसी भाषा है जिससे मैं अधिक परिचित हूं)।

हालांकि, GDScript पर विचार करने के लिए कुछ समस्याएं हैं:

• सबसे पहले, इसे लागू करना मामूली नहीं है। मैं देख सकता हूं कि अन्य भाषाएं इसे कैसे बनाती हैं, लेकिन फिर भी इसमें काफी समय लगेगा। इसलिए मैं एक समय में एक कदम आगे बढ़ना चाहता हूं और इस बारे में बाद में सोचना चाहता हूं। टाइपस्क्रिप्ट उसी व्यक्ति द्वारा बनाई गई थी जिसने टर्बो पास्कल और सी # बनाया था, इसलिए वहां बहुत अनुभव है जो मेरे पास नहीं है।
• GDScript एक समय में एक फ़ाइल संकलित की जाती है। क्रिस्टल और टाइपस्क्रिप्ट दोनों का उपयोग करने से पहले आपको पूरी परियोजना को संकलित करने की आवश्यकता है। इसका मतलब है कि अन्य लिपियों और सिंगलेट्स के साथ बातचीत की जांच करना थोड़ा मुश्किल है।
• दृश्य वृक्ष। get_node() (जिसका बहुत उपयोग किया जाता है) के साथ यह जानना असंभव है कि आपको कौन सा नोड प्रकार मिलेगा। आप केवल जानते हैं कि यह Node लेकिन यह किसी भी उपप्रकार का हो सकता है। जब आप load() कॉल करते हैं तो संसाधनों पर भी यही लागू होता है, खासकर यदि आप इसे गतिशील नाम से बुला रहे हैं। _input(event) में भी यही समस्या है, क्योंकि event कोई भी InputEvent उपप्रकार हो सकता है।

if my_var instanceof MyClass:
    ...

यह पहले से ही कोड पूरा करने के लिए अनुमान लगाया गया है। वास्तविक प्रकार की जाँच के लिए पुन: उपयोग किया जा सकता है। विशेष रूप से यह मामला मामूली है, लेकिन यह काफी उलझा सकता है। उदाहरण के लिए, यदि आप दूसरी शर्त जोड़ते हैं: if some value == 42 and my_var is Sprite , तो कोड पूर्णता अब काम नहीं करेगी।

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

संक्षेप में: मैं टाइप अनुमान में सुधार करना चाहता हूं, लेकिन इसे छोटे सुधारों के साथ कदम से कदम उठाना होगा। एक बार वैकल्पिक टाइपिंग उपलब्ध हो जाने के बाद, बाकी ऊपर की ओर है।

यह बंद क्यों है?

थोड़ा गलत पढ़ा, मेरा बुरा।

प्रीफ़िक्स और पोस्टफ़िक्स पर वापस जाएँ: यूएमएल और कोटलिन दोनों ": टाइप" का उपयोग करते हैं।
बेसिक ने भी "DIM a as INT" (और ":" या "is" के बजाय "as" का उपयोग किया)

@programaths तब से एक लंबा समय हो गया है, और इस पर बार-बार चर्चा की गई है। और भी, एक पीआर है जो पोस्टफिक्स लागू करता है, इसलिए यह अब सवाल से थोड़ा बाहर है: स्माइली:

क्या मुझे इसे बंद कर देना चाहिए?

@ लियोनार्डमेघेर 2 जब मेरा पीआर विलय हो जाएगा तो यह स्वचालित रूप से बंद हो जाएगा।

@ bojidar-bg मैं केवल कुछ स्थानों को जोड़ना चाहता था जहाँ पोस्टफ़िक्स का उपयोग किया जाता है क्योंकि यह अपने आप में दिलचस्प है। यूएमएल विश्लेषण और गैर-तकनीकी लोगों के लिए भी है। कोटलिन एक ऐसी भाषा है जिसे "प्रभावी जावा" को लागू करते हुए जावा की तुलना में अधिक आरामदायक और अधिक आधुनिक होने के लिए विकसित किया गया था।

इसलिए, यदि आपको यह लिखना है कि पोस्टफिक्स को क्यों चुना गया है, तो इन्हें भी शामिल किया जा सकता है। कभी-कभी, लोग कारण चाहते हैं और तकनीकी कारणों को आसानी से खारिज कर देते हैं जब तक कि आप उन्हें उपयोगकर्ता से संबंधित नहीं करते।
(उदाहरण के लिए "पार्सर पहले अस्पष्टताओं को हल कर सकता है और इसकी गति 100x है, जिसका अर्थ है कि एक ही प्रोग्राम को तेजी से संकलित किया जा सकता है और अधिक परीक्षण की अनुमति देता है)

सामग्री रखना हमेशा अच्छा होता है, है न ? ;-)