Kotlin: स्थिर जो मौजूद नहीं है

यह लेख कोटलिन में स्टैटिक्स का उपयोग करने के बारे में बात करेगा।
चलिए शुरू करते हैं।
कोटलिन का कोई स्थिर नहीं है!

यह आधिकारिक दस्तावेज में कहा गया है।

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

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

जावा में स्टेटिक क्या है? इस प्रकार हैं:

• स्थिर क्षेत्र
• स्थिर वर्ग विधियाँ
• स्थिर नेस्टेड कक्षाएं

आइए एक प्रयोग करें (यह पहली बात है जो दिमाग में आती है)।

एक साधारण जावा वर्ग बनाएँ:

public class SimpleClassJava1 { public static String staticField = "Hello, static!"; public static void setStaticValue (String value){ staticField = value; } } 

यहां सब कुछ आसान है: कक्षा में हम एक स्थिर क्षेत्र और एक स्थिर विधि बनाते हैं। हम बाहर से पहुंच के साथ प्रयोगों के लिए सार्वजनिक रूप से सब कुछ करते हैं। हम क्षेत्र और विधि को तार्किक रूप से जोड़ते हैं।

अब एक खाली कोटलिन वर्ग बनाएं और उसमें SimpleClassJava1 वर्ग की सभी सामग्रियों को कॉपी करने का प्रयास करें। हम रूपांतरण के बारे में पूछे गए प्रश्न का उत्तर "हाँ" देते हैं और देखते हैं कि क्या हुआ:

 class SimpleClassKotlin1 { var staticField = "Hello, static!" fun setStaticValue(value: String) { staticField = value } } 

ऐसा लगता है कि यह ठीक वैसा नहीं है, जिसकी हमें जरूरत है ... यह सुनिश्चित करने के लिए, हम इस वर्ग के बाईटेकोड को जावा कोड में बदल देंगे और देखेंगे कि क्या हुआ:

 public final class SimpleClassKotlin1 { @NotNull private String staticField = "Hello, static!"; @NotNull public final String getStaticField() { return this.staticField; } public final void setStaticField(@NotNull String var1) { Intrinsics.checkParameterIsNotNull(var1, "<set-?>"); this.staticField = var1; } public final void setStaticValue(@NotNull String value) { Intrinsics.checkParameterIsNotNull(value, "value"); this.staticField = value; } } 

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

वैसे, लगभग छह महीने पहले, एक ही जावा कोड को कोटलिन में परिवर्तित करने से थोड़ा अलग परिणाम दिखाई देता था। तो फिर से: स्वचालित रूपांतरण के साथ सावधान रहें!

हम आगे प्रयोग करते हैं।

हम कोटलिन पर किसी भी वर्ग में जाते हैं और उसमें जावा वर्ग के स्थिर तत्वों को कॉल करने का प्रयास करते हैं:

 SimpleClassJava1.setStaticValue("hi!") SimpleClassJava1.staticField = "hello!!!" 

यहाँ है कैसे! सब कुछ पूरी तरह से कहा जाता है, यहां तक ​​कि कोड का स्वत: पूर्ण होना हमें सब कुछ बताता है! बहुत उत्सुक है।

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

सबसे तेज़ और सबसे आसान चीज जिसे आप महसूस कर सकते हैं और उपयोग करना शुरू कर सकते हैं वह विकल्प है जिसे हम स्थिर विधियों - पैकेज स्तर के कार्यों के बजाय पेश किया जाता है। यह क्या है यह एक फ़ंक्शन है जो किसी भी वर्ग से संबंधित नहीं है। यही है, इस तरह का तर्क जो पैकेज स्पेस में कहीं शून्य में है। हम पैकेज के अंदर किसी भी फाइल में इसका वर्णन कर सकते हैं जो हमें रुचती है। उदाहरण के लिए, इस फ़ाइल को JustFun.kt नाम दें और इसे पैकेज com.example.mytestapplication

 package com.example.mytestapplication fun testFun(){ // some code } 

जावा में इस फ़ाइल के बाइटकोड को बदलें और अंदर देखें:

 public final class JustFunKt { public static final void testFun() { // some code } } 

हम देखते हैं कि जावा में एक वर्ग बनाया जाता है जिसका नाम उस फ़ाइल के नाम को ध्यान में रखता है जिसमें फ़ंक्शन का वर्णन किया गया है, और फ़ंक्शन स्वयं एक स्थिर विधि में बदल जाता है।

अब यदि हम पैकेज package com.example.mytestapplication (जो कि फंक्शन के समान पैकेज है) में स्थित एक वर्ग (या समान फ़ंक्शन) से testFun में testFun फ़ंक्शन को कॉल करना चाहते हैं, तो हम केवल अतिरिक्त ट्रिक्स के बिना उपयोग कर सकते हैं। यदि हम इसे दूसरे पैकेज से कहते हैं, तो हमें आयात करना होगा, जो हमारे लिए परिचित है और आमतौर पर कक्षाओं के लिए लागू होता है:

 import com.example.pavka.mytestapplication.testFun 

अगर हम Java कोड से function t estFun को कॉल करने के बारे में बात करते हैं, तो हमें हमेशा फंक्शन को इम्पोर्ट करने की आवश्यकता होती है, फिर चाहे हम इसे किस पैकेज के लिए देखें:

 import static com.example.pavka.mytestapplication.ForFunKt.testFun; 

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

आइए स्थैतिक तरीकों और क्षेत्रों को लागू करने के लिए अन्य विकल्पों को देखें।

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

कोटलिन हमें कुछ अतिरिक्त इकाई का उपयोग करने के लिए इन उद्देश्यों के लिए प्रदान करता है, जो एक एकल प्रति में भी मौजूद है। दूसरे शब्दों में, सिंगलटन।

कोटलिन के पास सिंगललेट्स घोषित करने के लिए एक ऑब्जेक्ट कीवर्ड है।

 object MySingltoneClass { // some code } 

इस तरह की वस्तुओं को प्रारंभिक रूप से आलसी किया जाता है, अर्थात्, उन्हें पहली कॉल के समय।

ठीक है, जावा में भी सिंगलेट्स हैं, जहां आँकड़े हैं?

कोटलिन में किसी भी वर्ग के लिए, हम एक साथी या साथी ऑब्जेक्ट बना सकते हैं। एक एकल वर्ग एक विशिष्ट वर्ग से जुड़ा हुआ है। यह एक साथ 2 companion object कीवर्ड का उपयोग करके किया जा सकता है:

 class SimpleClassKotlin1 { companion object{ var companionField = "Hello!" fun companionFun (vaue: String){ // some code } } } 

यहाँ हमारे पास SimpleClassKotlin1 वर्ग है, जिसके अंदर हम ऑब्जेक्ट कीवर्ड के साथ एक सिंगलटन घोषित करते हैं और इसे उस ऑब्जेक्ट से बाँधते हैं जिसके अंदर इसे साथी कीवर्ड के साथ घोषित किया जाता है। यहां आप इस तथ्य पर ध्यान दे सकते हैं कि, पिछले सिंगलटन घोषणा (MySingltoneClass) के विपरीत, सिंगलटन वर्ग का नाम इंगित नहीं किया गया है। यदि ऑब्जेक्ट को एक साथी घोषित किया जाता है, तो उसे अपने नाम को इंगित करने की अनुमति नहीं है। फिर इसे स्वचालित रूप से Companion नाम दिया जाएगा। यदि आवश्यक हो, तो हम इस तरह से साथी वर्ग का एक उदाहरण प्राप्त कर सकते हैं:

 val companionInstance = SimpleClassKotlin1.Companion 

हालांकि, एक साथी वर्ग के गुणों और तरीकों के लिए एक कॉल सीधे किया जा सकता है, एक कॉल के माध्यम से उस वर्ग के लिए जिसे यह संलग्न है:

 SimpleClassKotlin1.companionField SimpleClassKotlin1.companionFun("Hi!") 

यह पहले से ही स्थिर क्षेत्रों और कक्षाओं को कॉल करने की तरह दिखता है, है ना?

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

 interface FactoryInterface<T> { fun factoryMethod(): T } class SimpleClassKotlin1 { companion object : FactoryInterface<MyClass> { override fun factoryMethod(): MyClass = MyClass() } } 

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

ऑब्जेक्ट के रूप में घोषित वर्गों की बात करते हुए, हम कह सकते हैं कि हम उन में नेस्टेड ऑब्जेक्ट भी घोषित कर सकते हैं, लेकिन हम उनमें एक ऑब्जेक्ट ऑब्जेक्ट घोषित नहीं कर सकते।

यह देखने का समय है "हुड के नीचे।" हमारी सरल कक्षा लें:

 class SimpleClassKotlin1 { companion object{ var companionField = "Hello!" fun companionFun (vaue: String){ } } object OneMoreObject { var value = 1 fun function(){ } } 

अब जावा में इसके बाइटकोड को डिकंपाइल करें:

 public final class SimpleClassKotlin1 { @NotNull private static String companionField = "Hello!"; public static final SimpleClassKotlin1.Companion Companion = new SimpleClassKotlin1.Companion((DefaultConstructorMarker)null); public static final class OneMoreObject { private static int value; public static final SimpleClassKotlin1.OneMoreObject INSTANCE; public final int getValue() { return value; } public final void setValue(int var1) { value = var1; } public final void function() { } static { SimpleClassKotlin1.OneMoreObject var0 = new SimpleClassKotlin1.OneMoreObject(); INSTANCE = var0; value = 1; } } public static final class Companion { @NotNull public final String getCompanionField() { return SimpleClassKotlin1.companionField; } public final void setCompanionField(@NotNull String var1) { Intrinsics.checkParameterIsNotNull(var1, "<set-?>"); SimpleClassKotlin1.companionField = var1; } public final void companionFun(@NotNull String vaue) { Intrinsics.checkParameterIsNotNull(vaue, "vaue"); } private Companion() { } // $FF: synthetic method public Companion(DefaultConstructorMarker $constructor_marker) { this(); } } } 

हम देखते हैं कि क्या हुआ।

साथी ऑब्जेक्ट की संपत्ति को हमारी कक्षा के स्थिर क्षेत्र के रूप में दर्शाया गया है:

 private static String companionField = "Hello!"; 

यह वही प्रतीत होता है जो हम चाहते थे। हालाँकि, यह फ़ील्ड निजी है और हमारे साथी वर्ग के गेटटर और सेटर के माध्यम से एक्सेस की जाती है, जिसे यहाँ public static final class रूप में प्रस्तुत किया गया है, और इसका उदाहरण एक स्थिरांक के रूप में प्रस्तुत किया गया है:

 public static final SimpleClassKotlin1.Companion Companion = new SimpleClassKotlin1.Companion((DefaultConstructorMarker)null); 

साथी फंक्शन फंक्शन हमारी क्लास का स्टैटिक तरीका नहीं बन पाया (शायद ऐसा नहीं होना चाहिए)। यह सिंपलक्लासकोटलिन 1 क्लास में इनिशियलाइज़ किए गए एक सिंगलटन का फंक्शन रहा। हालांकि, अगर आप इसके बारे में सोचते हैं, तो तार्किक रूप से यह उसी चीज के बारे में है।

OneMoreObject क्लास के साथ OneMoreObject स्थिति बहुत समान है। यह केवल ध्यान देने योग्य है कि यहां, साथी के विपरीत, मूल्य वर्ग का क्षेत्र SimpleClassKotlin1 कक्षा में नहीं OneMoreObject , लेकिन OneMoreObject में बना रहा, लेकिन स्थिर भी हो गया और उत्पन्न गेटर और सेटर प्राप्त किया।

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

स्वतः पूर्ण हमें बताता है कि निम्नलिखित कॉल उपलब्ध हैं:

 SimpleClassKotlin1.Companion.companionFun("hello!"); SimpleClassKotlin1.Companion.setCompanionField("hello!"); SimpleClassKotlin1.Companion.getCompanionField(); 

यानी, यहां हम सीधे साथी के नाम का संकेत नहीं दे रहे हैं। तदनुसार, डिफ़ॉल्ट साथी ऑब्जेक्ट को असाइन किया गया नाम यहां उपयोग किया जाता है। बहुत सुविधाजनक नहीं है, है ना?

फिर भी, कोटलिन के रचनाकारों ने इसे जावा में अधिक परिचित बनाने के लिए संभव बना दिया। और ऐसा करने के कई तरीके हैं।

 @JvmField var companionField = "Hello!" 

अगर हम इस एनोटेशन को अपने companionField ऑब्जेक्ट के companionField फ़ील्ड पर लागू करते हैं, तो जब जावा को बाइट कोड परिवर्तित करते हैं, तो हम देखते हैं कि स्थिर फ़ील्ड का companionField Field SimpleClassKotlin1 अब निजी नहीं है, लेकिन सार्वजनिक है, और companionField गेट्टर और सेटर स्थिर Companion क्लास में चला गया है। अब हम सामान्य तरीके से Java कोड से companionField उपयोग कर सकते हैं।

दूसरा तरीका साथी lateinit की संपत्तियों के लिए एक lateinit संशोधक को निर्दिष्ट करना है, देर से प्रारंभ करने वाले गुण। यह मत भूलो कि यह केवल var-properties पर लागू होता है, और इसका प्रकार गैर-शून्य होना चाहिए और आदिम नहीं होना चाहिए। खैर, ऐसे गुणों से निपटने के नियमों के बारे में मत भूलना।

 lateinit var lateinitField: String 

और एक और तरीका: हम संशोधक कांस्टिट्यूशन को निर्दिष्ट करके साथी ऑब्जेक्ट की संपत्ति को स्थिर घोषित कर सकते हैं। यह अनुमान लगाना आसान है कि यह एक वैध संपत्ति होनी चाहिए।

 const val myConstant = "CONSTANT" 

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

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

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

 class SimpleClassKotlin1 { companion object{ @JvmStatic fun companionFun (vaue: String){ } @JvmStatic var staticField = 1 } } 

इस स्थिति में, निम्न कॉल जावा से मान्य हैं:

 int x; SimpleClassKotlin1.companionFun("hello!"); x = SimpleClassKotlin1.getStaticField(); SimpleClassKotlin1.setStaticField(10); SimpleClassKotlin1.Companion.companionFun("hello"); x = SimpleClassKotlin1.Companion.getStaticField(); SimpleClassKotlin1.Companion.setStaticField(10); 

निम्नलिखित कॉल कोटलिन से मान्य हैं:

 SimpleClassKotlin1.companionFun("hello!") SimpleClassKotlin1.staticField SimpleClassKotlin1.Companion.companionFun("hello!") SimpleClassKotlin1.Companion.staticField 

यह स्पष्ट है कि जावा के लिए आपको पहले 3 का उपयोग करना चाहिए, और कोटलिन के लिए पहला 2. शेष कॉल केवल मान्य हैं।

अब यह उत्तरार्द्ध को स्पष्ट करने के लिए है। स्थिर नेस्टेड वर्गों के बारे में क्या? यहां सब कुछ सरल है - कोटलिन में इस तरह के एक वर्ग का एनालॉग संशोधक के बिना एक नियमित नेस्टेड वर्ग है:

 class SimpleClassKotlin1 { class LooksLikeNestedStatic { } } 

बाइटकोड को जावा में बदलने के बाद, हम देखते हैं:

 public final class SimpleClassKotlin1 { public static final class LooksLikeNestedStatic { } } 

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

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

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

मेरे लिए यही सब है मुझे लगता है कि इस विषय को कुछ विस्तार से हल किया गया था। प्रश्न टिप्पणियों में लिखें।