Typescript: अंतिम कक्षाओं का समर्थन करें (गैर-उपवर्गीय)

निजी कंस्ट्रक्टर वाला वर्ग विस्तार योग्य नहीं है। इसके बजाय इसका उपयोग करने पर विचार करें।

मुझे जो याद आया उससे मुझे यकीन था कि कंपाइलर को कंस्ट्रक्टर पर प्राइवेट कीवर्ड पसंद नहीं आया। हो सकता है कि मैं हालांकि पेस्ट संस्करण का उपयोग नहीं कर रहा हूँ

यह एक नई सुविधा है, जिसे TS 2.0 में जारी किया जाएगा, लेकिन आप इसे typescript@next का उपयोग करके आज़मा सकते हैं। अधिक जानकारी के लिए https://github.com/Microsoft/TypeScript/pull/6885 देखें।

ठीक धन्यवाद

क्या निजी कंस्ट्रक्टर भी एक वर्ग को कक्षा से बाहर तत्काल नहीं बनाता है? यह अंतिम कक्षा का सही उत्तर नहीं है।

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

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

विधियों के लिए final संशोधक भी होना चाहिए:

class Foo {
  final fooIt():void{

  }
}

class Bar {
  fooIt():void {

  }
}
// => Method fooIt of Bar cannot override fooIt of Foo, because it is final.

उदाहरण के लिए, मैं अक्सर निम्नलिखित पैटर्न का उपयोग करता हूं, जहां मैं फू को ओवरराइड करने से तत्काल बचना चाहता हूं:

import Whatever ...

abstract class Foo {
  private ImportantVariable:boolean;

  protected abstract fooIt_inner:Whatever();

  public final fooIt():Whatever() {
    //do somestate change to aprivate member here, which is very crucial for the functionality of every Foo:
    ImportantVariable = true;
    //call the abstract inner functionality:
    return this.fooIt_inner();    
  }
}

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

समुदाय के सदस्यों को फ़ीडबैक जोड़ना जारी रखने की अनुमति देने के लिए समस्या को लॉक नहीं किया गया है। पर्याप्त प्रतिक्रिया और सम्मोहक उपयोग के मामलों के साथ, मुद्दों को फिर से खोला जा सकता है।

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

टाइपस्क्रिप्ट में ऐसा कुछ भी नहीं है जो हम आपके कोड को बिना फाइनल के चलाने से बेहतर बनाने की पेशकश कर सकते हैं।

वाह, क्रिंग! स्टेटिक प्रकार आपके कोड को बेहतर नहीं बनाते हैं, लेकिन सुरक्षा एक अच्छी बात है।

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

स्टेटिक प्रकार आपके कोड को बेहतर नहीं बनाते हैं, लेकिन सुरक्षा एक अच्छी बात है।

बिल्कुल। जिस तरह private दूसरों को विधि को कॉल करने से रोकता है, उसी तरह final दूसरों को विधि को ओवरराइड करने से रोकता है।

दोनों बाहरी दुनिया के साथ वर्ग के OO इंटरफ़ेस का हिस्सा हैं।

@pauldraper और @mindarelus से पूरी तरह सहमत हैं। कृपया इसे लागू करें, इससे बहुत कुछ समझ में आएगा कि मैं वास्तव में इसे वर्तमान में याद करता हूं।

मुझे नहीं लगता कि फाइनल केवल प्रदर्शन के लिए फायदेमंद है, यह डिजाइन के लिए भी फायदेमंद है लेकिन मुझे नहीं लगता कि यह टाइपस्क्रिप्ट में बिल्कुल भी समझ में आता है। मुझे लगता है कि Object.freeze और Object.seal के परिवर्तनशीलता प्रभावों को ट्रैक करके इसे बेहतर ढंग से हल किया गया है।

@aluanhaddad क्या आप इसे और विस्तार से समझा सकते हैं? आपको क्यों लगता है कि यह "टाइपस्क्रिप्ट में बिल्कुल भी समझ में नहीं आता"?
फ्रीजिंग या सीलिंग ऑब्जेक्ट का अर्थ है किसी ऑब्जेक्ट में नए गुणों को जोड़ने से रोकना, लेकिन किसी व्युत्पन्न ऑब्जेक्ट में गुणों को जोड़ने से नहीं रोकता है, भले ही मैं बेस क्लास को सील कर दूं, फिर भी मैं चाइल्ड क्लास में विधि को ओवरराइड कर सकता हूं, जो उस बेस क्लास को बढ़ाता है . इसके अलावा मैं रनटाइम पर बेस क्लास में कोई गुण नहीं जोड़ सका।

जावा में कक्षा या वर्ग विधि पर final का उपयोग करने का विचार मेरी राय में थ्रेड सुरक्षा के लिए वस्तु की उत्परिवर्तन को कम करने के साथ और अधिक करना है। (आइटम 15. जोशुआ बलोच, प्रभावी जावा)

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

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

निश्चित रूप से मैं इसके बिना रह सकता हूं, लेकिन यह किस टाइपस्क्रिप्ट का हिस्सा है, है ना? हमारी अनदेखी गलतियों की दोहरी जाँच?

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

@ hk0i इसका उल्लेख आइटम 17 (द्वितीय संस्करण) में भी उसी तरह किया गया है जैसा कि यहां प्रतिध्वनित किया गया है:

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

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

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

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

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

इस सूत्र में कई लोगों की तरह, मैं भी वर्ग को सील करने में सक्षम होने के लिए मतदान करूंगा।

@mhegazy निजी

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

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

एक कार्य है - कोड लिखें कि

• अपरिवर्तनीय वस्तुओं का संचालन करता है
• विरासत मुक्त है
• प्रतिबिंब के तरीके मुक्त

और final कीवर्ड यहां आवश्यक है, आईएमएचओ।

मैं final को अपने आप को और आपके कोड के उपयोगकर्ताओं को याद दिलाने के लिए एक शानदार तरीके के रूप में देखता हूं कि उन्हें कौन से संरक्षित तरीकों को ओवरराइड करना चाहिए, और जिन्हें उन्हें नहीं करना चाहिए। एक विचार के रूप में, मैं स्पष्ट रूप से यह कहने का समर्थक हूं कि आप ओवरराइड कर रहे हैं, आंशिक रूप से ताकि पाठक को पता चले, लेकिन यह भी कि यदि आप विधि का नाम टाइप करते हैं तो ट्रांसपिलर शिकायत करता है।

@zigszigsdk चूंकि विधियों को कभी भी ओवरराइड नहीं किया जाता है, यह कैसे काम करेगा?

final :
जिस तरह से यह अब काम करता है, ट्रांसपिलर को छोड़कर शिकायत होगी यदि कोई सुपर की विधि को छुपाता है-जिसे अंतिम घोषित किया गया है- this संदर्भ से।

override :
जिस तरह से यह अब काम करता है, ट्रांसपिलर को छोड़कर शिकायत होगी यदि कोई override विधि घोषित करता है, और उसके सुपर में उस नाम से कोई विधि नहीं है, या उसके पास एक है लेकिन इसे final घोषित किया गया है
यह संभवतः आपको चेतावनी भी दे सकता है यदि आप this संदर्भ से सुपर की विधि छुपाते हैं और ओवरराइड नहीं बताते हैं।

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

@mhegazy बिल्कुल नहीं! एक अन्य महत्वपूर्ण कार्य यह स्पष्ट करना है कि कक्षा के किन हिस्सों को ओवरराइड होने की उम्मीद है।

उदाहरण के लिए, "प्रभावी जावा" में आइटम 17 देखें: "विरासत के लिए डिज़ाइन और दस्तावेज़ या अन्यथा इसे प्रतिबंधित करें":

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

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

मुझे लगता है कि final कक्षाएं और विधियां बहुत महत्वपूर्ण हैं। मुझे आशा है कि आप इसे लागू करेंगे।

एक और सम्मोहक उपयोगकर्ता मामला @mhegazy । आज मैंने टेम्प्लेट मेथड पैटर्न सीखा, और पाया कि विकिपीडिया में टेम्प्लेट मेथड पैटर्न के अनुसार final की आवश्यकता है। लेकिन मैं इसे अपने प्यारे टाइपस्क्रिप्ट में नहीं कर सकता। अफ़सोस की बात है!

टेम्प्लेट पैटर्न उपवर्गों को एल्गोरिथम की संरचना को बदले बिना एल्गोरिथम के कुछ चरणों को फिर से परिभाषित करने देता है

मेरे लिए यह विरासत के मामलों में संरचना को लागू करने की कोशिश करने जितना आसान है। फाइनल के बिना आप ऐसा नहीं कर सकते।

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

मैं इस मुद्दे को फिर से खोलना और कार्यान्वित होते देखना चाहता हूं।

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

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

इस विषय पर मेरे 5 सेंट हैं कि इसे फिर से खोला जाना चाहिए और लागू किया जाना चाहिए।

मैं इसका उपयोग पुस्तकालयों के ग्राहकों को अपने स्वयं के ठोस वर्ग बनाने के लिए लागू करने के लिए करता हूं और पहले से मौजूद किसी अन्य से नहीं फैलता है। जैसे @lucasyvas ने कहा, रचना का पक्ष लें। या उदाहरण के लिए कोणीय में निर्भरता इंजेक्शन प्रदान करने के लिए बस नए ठोस वर्ग कार्यान्वयन को लागू करें।

मैं दोनों वर्गों और विधियों के समर्थन के साथ, फिर से खोलने के लिए भी वोट करता हूं

मैं यह नहीं कहता कि हमें यह नहीं कहना चाहिए कि टाइपस्क्रिप्ट के संदर्भ में अंतिम कीवर्ड का पैटर्न कैसे काम करेगा?

क्या अंतिम कीवर्ड उपयोगकर्ताओं/प्रोग्रामर को उक्त वर्ग/विधि से ओवरराइड/इनहेरिट करने से नहीं रोकेगा?

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

@niokasgami फ्रीज [डेटा] से संबंधित है (https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/Object/freeze)
और पहले से ही ES6 के भाग के रूप में उपलब्ध है। अंतिम कक्षाओं और विधियों पर लागू होता है (चर केवल पढ़ने के लिए हो सकता है और इसलिए "अंतिम" के रूप में कार्य करता है क्योंकि हम एक सुपर चर को ओवरराइड नहीं कर सकते हैं)।

जावा में "फाइनल" कीवर्ड का उपयोग किया जाता है जहां सीलबंद सी # में होता है ।

जैसा कि टाइपस्क्रिप्ट सी # से दृढ़ता से प्रेरित है, इस बात की अधिक संभावना होनी चाहिए कि "सीलबंद" चुना जाएगा। अब, हमें संभवतः ES6 सील के साथ भ्रम हो सकता है जो मूल रूप से रनटाइम पर ऑब्जेक्ट को सील कर देता है?

@Xample मुझे लगता है कि आप जावा में स्थानीय चर पर फाइनल का भी उपयोग कर सकते हैं। मुझे याद है कि जब मैं एंड्रॉइड ऐप लिख रहा था तो मुझे ऐसा करना पड़ा। मुझे लगता है कि मुझे इसे एक कार्यक्रम के साथ करने की आवश्यकता है लेकिन मैं 100% निश्चित नहीं हूं।

function(){
    let final myVariable = 'Awesome!'
    document.addEventListener('scroll', e => {
        console.log(myVariable)
        myVariable = 'Not Awesome' // Throws an error
    })
}

@TheColorRed खैर, जावा में अंतिम स्थानीय चर का अर्थ स्थिर है, है ना?

@EternalPhane मुझे ऐसा लगता है, मैंने हमेशा वैश्विक जैसे दायरे में const का उपयोग किया है ... किसी फ़ंक्शन या विधि के भीतर इसका उपयोग करने के बारे में कभी नहीं सोचा ... मुझे लगता है कि पिछली टिप्पणी शून्य है ...

@Xample हाँ, मैं सी # से मुहरबंद के लिए आपका बिंदु देखता हूं, यह मेरी राय में ईमानदारी से काम नहीं कर रहा है, दोनों कीवर्ड मुहर और फाइनल वास्तव में श्रेणी में प्रवेश नहीं कर सके क्योंकि दोनों भ्रमित हो सकते हैं (सील आदि के लिए मुहरबंद) और अंतिम हम अनिश्चित हैं इसे कैसे लागू किया जाए क्योंकि जावा में इसका उपयोग स्थिरांक के रूप में किया जाता है: /

जावा में आप final किसी भी वेरिएबल, मेथड या क्लास कर सकते हैं। चर के लिए इसका मतलब है कि संदर्भों को पुन: असाइन नहीं किया जा सकता है (गैर-संदर्भ प्रकारों के लिए इसका मतलब है कि आप उनके मूल्यों को भी नहीं बदल सकते हैं)। कक्षाओं के लिए इसका मतलब कोई एक्सटेंशन नहीं है ( extends ... कीवर्ड)। विधियों के लिए इसका मतलब उपवर्गों में कोई ओवरराइडिंग नहीं है।

जावा में final मुख्य कारण:

• चर की अपरिवर्तनीयता कम करें: थ्रेड सुरक्षा के लिए
• कक्षाओं को अंतिम रूप दें ताकि उन्हें विरासत में नहीं मिल सके: विरासत पर संरचना को बल देता है क्योंकि जब आपके उपवर्ग अनजाने में सुपर विधियों को कॉल करना शुरू करते हैं तो विरासत स्वाभाविक रूप से जटिल होती है
• सरल प्रोग्रामिंग त्रुटियों को रोकता है: यदि आपका कोई मूल्य बदलने का कोई इरादा नहीं है, तो अच्छी खबर यह अब संभव नहीं है
• जब वे स्थिरांक की कल्पना करते हैं तो अधिकांश लोग क्या सोचते हैं इसके लिए उपयोग किया जाता है: पुन: प्रयोज्य मान जो आप हर जगह देखेंगे, जैसे public static final String KEY = "someStringKeyPathHere" , गलतियों को कम करने के लिए उपयोगी है, लेकिन एक ही मूल्य के लिए एकाधिक स्ट्रिंग ऑब्जेक्ट्स को दोबारा नहीं बनाने का एक अतिरिक्त संकलन समय लाभ है

मैंने कुछ उपयोग के मामलों को छोड़ दिया हो सकता है लेकिन मैं इसे बहुत सामान्य रखने और कुछ उदाहरण देने की कोशिश कर रहा था।

@TheColorRed एंड्रॉइड को इसकी आवश्यकता होती है जब आप कॉलबैक (अनाम वर्ग) के बाहर एक चर घोषित करते हैं और फिर इसे अंदर संदर्भित करते हैं। मुझे लगता है कि यह थ्रेड सुरक्षा मुद्दों के साथ फिर से संरेखित है। मुझे लगता है कि वे आपको किसी अन्य थ्रेड से वैरिएबल को पुन: असाइन करने से रोकने की कोशिश कर रहे हैं।

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

मुझे लगता है कि वास्तविक रूप से भले ही आप इनमें से कुछ लाभों के लिए कलाई पर एक थप्पड़ दे सकते हैं, आपको जावा-एस्क final के वास्तविक लाभों में से कोई भी जेएस में परिवर्तित होने के बाद नहीं मिलता है।

@ hk0i मुझे लगता है कि मैं आपकी बात समझ सकता हूं लेकिन कुल मिलाकर मैं सहमत हूं और आपकी राय के बारे में एक ही समय में असहमत हूं।

टाइपस्क्रिप्ट में अधिकांश कोड मैं प्रोग्रामर को अच्छी तरह से मदद करने के लिए डिबगिंग/ट्रैकिंग उद्देश्य के लिए कहूंगा, मुझे लगता है कि "क्लीन" कोड है (कृपया मुझे उस पर उद्धरण न दें, मुझे पता है कि उनके पास यहां कुछ टाइपस्क्रिप्ट स्पेगेटी कोड है)

अधिकांश टाइपस्क्रिप्ट सुविधा JS में परिवर्तित होने पर अधिकांश समय ट्रांसपिल्ड नहीं होती है क्योंकि वे JS में मौजूद नहीं होती हैं।

यद्यपि जब आप अपना कोड रनटाइम/लिखते हैं तो यह आपके कोड में त्रुटि देखने और जेएस की तुलना में इसे अधिक आसानी से ट्रैक करने में मदद करता है (और एचईसीके जेएस बग को ट्रैक करना मुश्किल हो सकता है)

तो मुझे लगता है कि अंतिम कीवर्ड का उपयोग एपीआई उपयोगकर्ता के लिए अवरोधक के रूप में देखा जा सकता है: ओह ठीक है, इस वर्ग को विस्तारित नहीं किया जाना चाहिए क्योंकि इसका विस्तार अजीब व्यवहार आदि को उत्तेजित कर सकता है ...

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

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

वर्तमान ES6 समाधानों पर निर्भर करते हुए एक रनटाइम परिवर्तनशीलता जांच (ऑब्जेक्ट.सील या ऑब्जेक्ट.फ्रीज़ का उपयोग करके) जोड़ने से आप अपना कोड टाइप करते समय सीधे त्रुटियां होने का लाभ खो देते हैं (भले ही यह इस डेकोरेटर का उपयोग करके आसानी से किया जा सकता है)।

@TheColorRed हाँ ... और टाइपस्क्रिप्ट में हमारे पास स्थानीय और वर्ग चर के लिए एक अंतर है।

• readonly एक वर्ग चर के लिए
• const : किसी भी अन्य चर के लिए

उनमें से कोई भी विधि या वर्ग के लिए सटीक नहीं होगा। एक विधि को ओवरराइड करने का मतलब यह नहीं है कि हम इसे फिर से परिभाषित कर रहे हैं (सी ++ में आभासी तरीकों में सोचें), हम सिर्फ एक विधि को परिभाषित करते हैं जिसे सुपर से पहले प्राथमिक कहा जाएगा (जिसे हम super का उपयोग करके कॉल कर सकते हैं)।

@niokasgami शायद नामकरण वास्तव में कोई समस्या नहीं है क्योंकि हम अभी भी समझेंगे कि Object.seal एक वर्ग और संरचना के लिए एक विधि को सील करते समय एक वस्तु पर लागू होता है।

टीएल; डॉ:

• रोकथाम एक्सटेंशन विस्तारित कक्षाओं को रोकने के लिए एक अच्छा स्पष्ट नाम होगा
• रोकथाम ओवरराइड कक्षाओं को ओवरराइड करने से रोकने के लिए एक अच्छा उम्मीदवार नाम होगा
  लेकिन: seal व्यापक रूप से C# में उपयोग किया जाता है, छोटा और समान अपेक्षित व्यवहार है।

वैसे मैं उल्लेख करना भूल गया कि Object.preventExtensions()
अंतर यहां देखा जा सकता

अध्ययन

• हमेशा संभव है... कौन केवल लेखन चर चाहता है?

अद्यतन करना और हटाना

• एक चर को हटाने को फिर से परिभाषित करने से रोकें: कक्षा के सदस्य के लिए केवल पढ़ने के लिए, कॉन्स (किसी अन्य के लिए)
• एक विधि को फिर से परिभाषित करने से रोकें: कुछ भी आपको (कक्षा विधि के भीतर) this.aMethod = ()=>{} करने से नहीं रोकता है। क्या ऐसे हैक्स को रोकने के लिए तरीके readonly भी होने चाहिए? delete this.aMethod

बनाना

• केवल वस्तु पर लागू होता है या जैसा कि हम यहां संरचना के बारे में बात कर रहे हैं: class जैसा कि वर्ग ने वस्तु के सदस्यों को परिभाषित किया है, टाइपस्क्रिप्ट पहले से ही मक्खी पर नए गुण बनाने से रोकता है ... उदाहरण के लिए this.unKnownProperty = "something" ts उम्मीद के मुताबिक संकलन समय त्रुटि

विस्तार

• केवल वर्गों पर लागू होता है, हम कुछ भी वस्तु ही अभी तक पर नहीं कर रहे हैं ... (बनाने जो रनटाइम पर है के विपरीत)। यह वह जगह है जहां final या seal प्रासंगिक होगा। सवाल यह है कि ES6 के फ्रीज, सील और preventExtensions के साथ लगातार कैसे बने रहें? (अगर हमें करना है)।
  एक वर्ग का विस्तार करने का मतलब है कि हम इस वर्ग से दूसरी कक्षा बनाने से रोकते हैं। फिर हम इसे पढ़ सकते हैं लेकिन डिलीट नहीं कर सकते (जो वैसे भी क्लास को डिलीट करता है)। सवाल "अपडेट" कॉलम नहीं है। क्या final वर्ग अद्यतन करने योग्य है? एक वर्ग अद्यतन करने योग्य क्या है? मेरा अनुमान हाँ है ... लेकिन फिर अद्यतन इस वर्ग को लागू करना होगा (कक्षा के इंटरफ़ेस को समझना)? किसी अन्य वर्ग को लागू करना हमेशा संभव होना चाहिए... लेकिन यह प्रारंभिक वर्ग को अद्यतन करने से संबंधित नहीं है। खैर ... शायद वे सी # लिखने वाले एक ही प्रश्न पर आए और फैसला किया कि seal अच्छा कीवर्ड था।

अधिभावी

• एक विस्तारित वर्ग में वर्तमान विधि को ओवरराइड करने से रोकें। फिर से, हम अभी तक कुछ भी ओवरराइट नहीं कर रहे हैं क्योंकि हम एक परिभाषा (एक वर्ग के भीतर विधि) के बारे में बात कर रहे हैं। इसलिए बनाने से रोकें, पढ़ने की अनुमति दें, अपडेट करने की अनुमति दें (हम विधि को अपडेट करने से रोक सकते हैं या इसे केवल पढ़ने के लिए उपयोग करके हटा सकते हैं यदि यह विधियों पर भी लागू होता है)। सबसे अच्छा नामकरण? preventOverrides ? या फिर seal जैसा कि C# में उपयोग किया जाता है

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

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

... अगर मैं सही ढंग से समझ रहा हूँ।

@ hk0i जेनरिक, केवल पढ़ने के लिए, और कई अन्य सुविधाएँ जावास्क्रिप्ट सुविधाएँ नहीं हैं, लेकिन वे अभी भी टाइपस्क्रिप्ट में जोड़े गए हैं, इसलिए मुझे नहीं लगता कि यही कारण है ...

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

final संकलन समय पर भी "मिटा" जा सकता है, तो यह इसे "निष्पक्ष खेल" क्यों नहीं बनाता है?

‍♂️

@TheColorRed मुझे लगता है कि यह कमोबेश या तो उन्हें एकीकृत करने की अन्य प्राथमिकता है।
या वे अनिश्चित हैं कि यह नया कीवर्ड कंपाइल/कोडिंग समय पर कैसे काम कर सकता है। यदि आप इसके बारे में सोचते हैं तो अंतिम कीवर्ड का डिज़ाइन बेहद अस्पष्ट हो सकता है। final कई उद्देश्यों के लिए बहुत उपयोग किया जा सकता है। जैसा कि आप Jsdoc दस्तावेज़ों से देख सकते हैं कि आप "@ final" टैग का उपयोग कर सकते हैं जो jsdoc दुभाषिया को बताता है कि यह चर इस प्रकार केवल पढ़ने के लिए जमे हुए है।

यहाँ एक डिजाइन संघर्ष। रीडोनली वैरिएबल और गेट्टर पर लागू होता है अगर मुझे याद है कि वेरिएबल को "फ्रीज" किया गया है और इसे केवल पढ़ने के लिए और अंतिम रूप से इसे अंतिम रूप से भी पढ़ा जाता है।

यह प्रोग्रामर के लिए भ्रम पैदा कर सकता है जो अनिश्चित है कि क्या उन्हें अपने वेरिएबल्स को अंतिम या केवल पढ़ने के लिए टैग करना चाहिए।

जब तक हम इस कीवर्ड को विशेष रूप से वर्ग और विधि घोषणाओं के लिए आरक्षित नहीं करते हैं, मुझे लगता है कि व्यवहार या अंतिम केवल पढ़ने के लिए संघर्ष करेगा।

मुझे लगता है कि सीलबंद (जो ऑब्जेक्ट.सील के साथ संघर्ष कर सकता है) या फाइनल (जो इस उद्देश्य के डिजाइन क्लैश रीडोनली कीवर्ड) के बजाय हम इसे नाम और डिजाइन करने के लिए और अधिक "प्रत्यक्ष" तरीके से जा सकते हैं।

ध्यान दें कि यह केवल एक व्यवहार का "विचार" है जो समान है लेकिन साथ ही सी # व्यवहार से अलग है? मैंने कुछ प्रेरणाएँ लीं कि कैसे C# सामान्य रूप से गैर-अनिवार्य है और फिर आपको यह कहना होगा कि यह विधि आभासी है।

`नेमस्पेस उदाहरण {

export class myClass {

    constructor(){}

    // Make the func non ovveridable by inheritance. 
    public unoveridable myMethod(){

    }

    public myMethodB(){

    }
}

export class MyClassB extends myClass {

    // Nope not working will throw an error of an nonOverridable error
    myMethod(){
        super.myMethod();
    }

    // Nope will not work since unoverridable.
    myMethod(){

    }

    // Design could be implemented differently since this could complicate  ¸
    // the pattern of typescript
    public forceoverride myMethod(){
      // destroy previous pattern and ignore the parent method thus a true ovveride
    }

    // Yup will work since it's still "virtual".
    myMethodB(){
        super.myMethodB();
    }
}
// Can extend an existing Parent class
// Declaring an unextendable class make all is component / func nonOverridable by 
// inheritance. (A class component can still be overwritten by prototype usage.)
export unextendable class MyFinalClass extends Parent {

    constructor()

    // nonoverridable by default.
    public MyMethod(){

    }
}
// nope throw error that MyFinalClass is locked and cannot be extended
export class MyChildClass extends MyFinalClass{}

}`

संपादित करें: मैंने वेरिएबल को शामिल नहीं किया और प्राप्त करें क्योंकि रीडोनली पहले से मौजूद है।

@mhegazy कृपया इस मुद्दे को फिर से खोलने पर विचार करें। जावा ( final ), C# ( sealed , readonly ), PHP जैसे final कीवर्ड जोड़ने के पक्ष में समुदाय प्रतिक्रिया भारी प्रतीत होती है ( final ), स्काला ( final , sealed ), और C++ ( final , virtual ) है। मैं एक स्थिर रूप से टाइप की गई ओओपी भाषा के बारे में नहीं सोच सकता जिसमें यह सुविधा नहीं है, और मैंने एक ठोस तर्क नहीं सुना है कि टीएस को इसकी आवश्यकता क्यों नहीं है।

@bcherny @mhegazy मैं उपरोक्त से पूरी तरह सहमत हूं। मैं कोई भी तर्कपूर्ण कारण नहीं देख सकता कि क्यों final सिर्फ एक और संकलन-समय की बाधा नहीं हो सकता है, जैसे कि अधिकांश वाक्यात्मक चीनी जो हम टाइपस्क्रिप्ट में देखते हैं - आइए इसका सामना करते हैं, स्थिर टाइपिंग, जेनरिक, एक्सेस संशोधक, उपनाम टाइप करें , इंटरफेस ... सभी चीनी! मुझे लगता है कि टाइपस्क्रिप्ट टीम शायद भाषा को अन्य दिशाओं में ले जाने पर ध्यान केंद्रित करना चाहती है, लेकिन गंभीरता से, यह ओओपी 101 है ... यह बहुत समय पहले होना चाहिए था, जब टाइपस्क्रिप्ट अभी भी बहुत छोटा था!

@mhegazy क्या मैं आपको इस मुद्दे पर आपके द्वारा की गई प्रारंभिक टिप्पणी के बारे में

निजी कंस्ट्रक्टर वाला वर्ग विस्तार योग्य नहीं है। इसके बजाय इसका उपयोग करने पर विचार करें।

इस टिप्पणी को लिखे जाने तक 21 बार डाउन-वोट किया जा चुका है।
स्पष्ट रूप से यह वह नहीं है जो समुदाय समाधान के रूप में चाहता है!

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

यहाँ बहुत सारी अनुत्पादक शिकायतें चल रही हैं। कृपया केवल आवाज न उठाएं - हमें यहां निर्णय लेने की अनुमति है और समुदाय को अपनी प्रतिक्रिया देने की अनुमति है, लेकिन केवल बेकार दांत पीसने से किसी का विचार नहीं बदलने वाला है। कृपया विशिष्ट और कार्रवाई योग्य बनें; हम लोगों द्वारा केवल यह कहने के लिए आश्वस्त नहीं होने जा रहे हैं कि

ध्यान दें कि यह मुद्दा अंतिम/सीलबंद कक्षाओं के बारे में है। अंतिम/मुहरबंद विधियों की ऑफ-विषय चर्चा हुई है जो एक पूरी तरह से अलग अवधारणा है।

पिछली बार जब हमने इसकी समीक्षा की थी तब कुछ बिंदुओं पर विचार किया गया था

• कक्षाएं एक जावास्क्रिप्ट सुविधा हैं, टाइपस्क्रिप्ट सुविधा नहीं । यदि आप वास्तव में ऐसा महसूस करते हैं कि final बिना कक्षाएं पूरी तरह से बेकार हैं, तो यह TC39 समिति के साथ उठाने या es-चर्चा करने के लिए कुछ है। यदि कोई भी TC39 को यह समझाने के लिए तैयार या सक्षम नहीं है कि final एक अनिवार्य विशेषता है, तो हम इसे टाइपस्क्रिप्ट में जोड़ने पर विचार कर सकते हैं।
• यदि किसी चीज़ पर new का आह्वान करना कानूनी है, तो इससे विरासत में मिलने वाला एक-से-एक रनटाइम पत्राचार है। किसी ऐसी चीज़ की धारणा जो new 'd हो सकती है लेकिन super 'd नहीं हो सकती है, जावास्क्रिप्ट में मौजूद नहीं है
• हम टाइपस्क्रिप्ट को OOP कीवर्ड सूप में बदलने से बचने की पूरी कोशिश कर रहे हैं। जावास्क्रिप्ट में विरासत की तुलना में कई बेहतर रचना यांत्रिकी हैं और हमें सी # और जावा के हर एक कीवर्ड की आवश्यकता नहीं है।
• आप "चाहिए-अंतिम" वर्ग से विरासत का पता लगाने के लिए एक रनटाइम चेक को तुच्छ रूप से लिख सकते हैं, जिसे आपको वास्तव में वैसे भी करना चाहिए यदि आप किसी ऐसे व्यक्ति के बारे में "चिंतित" हैं जो गलती से आपकी कक्षा से विरासत में मिला है क्योंकि आपके सभी उपभोक्ता टाइपस्क्रिप्ट का उपयोग नहीं कर रहे हैं .
• आप एक शैलीगत सम्मेलन को लागू करने के लिए एक लिंट नियम लिख सकते हैं जो कुछ वर्गों से विरासत में नहीं मिला है
• परिदृश्य है कि किसी को "गलती से" आपके द्वारा सील की जाने वाली कक्षा से विरासत में मिला होगा, एक अजीब तरह का है। मैं यह भी तर्क दूंगा कि किसी व्यक्ति का व्यक्तिगत मूल्यांकन किसी दिए गए वर्ग से प्राप्त करने के लिए "संभव" है या नहीं, शायद यह संदिग्ध है।
• किसी वर्ग को सील करने के मूल रूप से तीन कारण हैं: सुरक्षा, प्रदर्शन और आशय। उनमें से दो टाइपस्क्रिप्ट में कोई मतलब नहीं रखते हैं, इसलिए हमें किसी ऐसी चीज की जटिलता बनाम लाभ पर विचार करना होगा जो अन्य रनटाइम में केवल 1/3 काम कर रही है।

आप इन सभी से असहमत होने के लिए स्वतंत्र हैं, लेकिन कृपया इस बारे में कुछ कार्रवाई योग्य और विशिष्ट प्रतिक्रिया दें कि कैसे final की कमी जावास्क्रिप्ट कक्षाओं का प्रभावी ढंग से उपयोग करने की आपकी क्षमता को नुकसान पहुंचा रही है।

टीएस को इसकी आवश्यकता क्यों नहीं है, इसके लिए एक ठोस तर्क नहीं सुना है

बस एक अनुस्मारक कि यह कैसे काम नहीं करता है। सभी सुविधाएं -100 से शुरू होती हैं । उस पोस्ट से

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

हमारे पास एक सीमित जटिलता बजट है। हम जो कुछ भी करते हैं वह हर अगले काम को 0.1% धीमा कर देता है। जब आप किसी सुविधा का अनुरोध करते हैं, तो आप अनुरोध कर रहे हैं कि हर दूसरी सुविधा थोड़ी कठिन, थोड़ी धीमी, थोड़ी कम संभव हो जाए। यहां दरवाजे में कुछ भी नहीं मिलता है क्योंकि जावा के पास है या क्योंकि सी # के पास है या क्योंकि यह केवल कोड की कुछ पंक्तियां होगी या आप कमांडलाइन स्विच जोड़ सकते हैं । सुविधाओं को अपने लिए और भविष्य पर उनके पूरे बोझ के लिए भुगतान करना होगा।

@RyanCavanaugh जबकि मुझे यकीन नहीं है कि मैं निर्णय से सहमत हूं, मैं वास्तव में विचारशील और विस्तृत प्रतिक्रिया की सराहना करता हूं, और इसे लिखने के लिए समय निकालने के लिए। मुझे लगता है कि आप भाषा को दुबला रखना चाहते हैं - इस पर विचार करना अच्छा है कि क्या अन्य लोकप्रिय भाषाओं की विशेषताएं वास्तव में मूल्यवान हैं, या केवल सामान्य हैं।

@RyanCavanaugh

मुझे नहीं लगता कि यहां इस मंच में बिंदु है .. "प्रभावी ढंग से जावास्क्रिप्ट कक्षाओं का उपयोग करें।"

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

हम टाइपस्क्रिप्ट को OOP कीवर्ड सूप में बदलने से बचने की पूरी कोशिश कर रहे हैं। जावास्क्रिप्ट में विरासत की तुलना में कई बेहतर रचना यांत्रिकी हैं ...

जैसे जब आप final का उपयोग विरासत पर संरचना को लागू करने के लिए करते हैं (यहां टाइपस्क्रिप्ट भाषा का नाम नहीं डालें)
(क्षमा करें, मैं विरोध नहीं कर सका)

लेकिन अधिक बिंदु पर, ऐसा लगता है कि टीएस ज्यादातर "आज की जावास्क्रिप्ट अब" या उस प्रभाव के लिए कुछ (एक ला बेबेल) को पेश करने के लिए एक संगतता परत होने का इरादा रखता है, अपवाद के साथ कि यह कुछ अतिरिक्त प्रकार की जांच जोड़ता है।

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

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

मुख्य बात यह है कि यदि आप टाइपस्क्रिप्ट से खुश नहीं हैं, तो इसका उपयोग न करें।

@RyanCavanaugh

आपके द्वारा ऊपर उठाए गए बिंदुओं पर...

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

मैं 0.7 से टाइपस्क्रिप्ट का अनुसरण कर रहा हूं और उसके बाद, IIRC यह ES3-ES5 को लक्षित कर रहा था। उस समय कक्षाएं निश्चित रूप से एक टाइपस्क्रिप्ट सुविधा थीं। वही तर्क सज्जाकारों पर लागू होता है - वे ES के लिए कार्ड पर हैं, लेकिन वे पहले से ही टाइपस्क्रिप्ट में एक प्रयोगात्मक सुविधा के रूप में हैं।

एक समुदाय के रूप में, हम यह तर्क नहीं दे रहे हैं कि टाइपस्क्रिप्ट कंपाइलर को किसी तरह एक जावास्क्रिप्ट वर्ग का उत्सर्जन करना चाहिए जो कि final । एक कंपाइल-टाइम चेक पर्याप्त होगा, उसी तरह जो एक्सेस मॉडिफायर के लिए कंपाइल टाइम चेक पर्याप्त है; आखिरकार, वे जावास्क्रिप्ट सुविधाएँ भी नहीं हैं, लेकिन टाइपस्क्रिप्ट अभी भी उन्हें संभव बनाता है।

यदि final एक ES सुविधा बन गया है, तो संभवतः आप final उचित रूप से आउटपुट करने के लिए ES* को लक्षित करते समय उत्सर्जक के उस बिट को पुन: सक्रिय कर सकते हैं (उसी में जो आपने कक्षाओं के लिए किया था, जब उन्हें पेश किया गया था) ES6 में)?

यदि किसी चीज़ पर new का आह्वान करना कानूनी है, तो इससे विरासत में मिलने वाला एक-से-एक रनटाइम पत्राचार है। किसी ऐसी चीज़ की धारणा जो new 'd हो सकती है लेकिन super 'd नहीं हो सकती है, जावास्क्रिप्ट में मौजूद नहीं है

दोबारा, मुझे नहीं लगता कि समुदाय आपसे उम्मीद कर रहा है कि आप यहां कुछ जादू करेंगे ताकि रनटाइम पर final लागू किया जा सके। जैसा कि आपने सटीक रूप से कहा है, यह "जावास्क्रिप्ट में मौजूद नहीं है", लेकिन जैसा कि बताया गया है, एक संकलन-समय की बाधा पर्याप्त होगी।

हम टाइपस्क्रिप्ट को OOP कीवर्ड सूप में बदलने से बचने की पूरी कोशिश कर रहे हैं। जावास्क्रिप्ट में विरासत की तुलना में कई बेहतर रचना यांत्रिकी हैं और हमें सी # और जावा के हर एक कीवर्ड की आवश्यकता नहीं है।

यह संपूर्ण रूप से सॉफ़्टवेयर विकास समुदाय में एक प्रसिद्ध वाक्यांश है: "विरासत पर रचना का पक्ष लें", हालांकि "पक्ष" का अर्थ यह नहीं है कि विरासत को एक कंबल कथन के रूप में abstract कक्षाओं (जो कि "जावास्क्रिप्ट में मौजूद नहीं है") की अनुमति देने के लिए एक तर्क होना चाहिए, तो क्यों नहीं final कक्षाएं?

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

सी # और जावा के लिए भी यही कहा जा सकता है, लेकिन मुझे रनटाइम चेक की आवश्यकता नहीं है क्योंकि मेरे पास कंपाइलर स्तर पर ऐसा करने के लिए sealed और final है।

यदि मेरे सभी उपभोक्ता टाइपस्क्रिप्ट का उपयोग नहीं कर रहे थे, तो मुझे केवल final वर्ग से विरासत में प्राप्त होने की तुलना में चिंता करने के लिए और भी बहुत कुछ होगा; उदाहरण के लिए, private या protected सदस्यों तक abstract वर्ग बनाने की क्षमता।

क्या हमारे कोड को वास्तव में इन सभी चीजों के लिए रनटाइम चेक से भरा होना चाहिए (जिनमें से कुछ भी संभव नहीं हैं जिन्हें मैं जोड़ सकता हूं) बस यह सुनिश्चित करने के लिए कि हमारे गैर-टाइपस्क्रिप्ट उपभोक्ता यथासंभव सुरक्षित हैं?

आप एक शैलीगत सम्मेलन को लागू करने के लिए एक लिंट नियम लिख सकते हैं जो कुछ वर्गों से विरासत में नहीं मिला है

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

परिदृश्य है कि किसी को "गलती से" आपके द्वारा सील की जाने वाली कक्षा से विरासत में मिला होगा, एक अजीब तरह का है। मैं यह भी तर्क दूंगा कि किसी व्यक्ति का व्यक्तिगत मूल्यांकन किसी दिए गए वर्ग से प्राप्त करने के लिए "संभव" है या नहीं, शायद यह संदिग्ध है।

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

क्या से शुरू होने वाले प्रश्न पूछने से मैं आमतौर पर कर सकता हूं जो मुझे चाहिए ।

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

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

मुझे नहीं लगता कि final नहीं होने से जावास्क्रिप्ट कक्षाओं का प्रभावी ढंग से उपयोग करने की मेरी क्षमता को नुकसान हो रहा है, न ही जावास्क्रिप्ट कक्षाएं इसके बिना अनुपयोगी हैं। मुझे लगता है कि final एक "आवश्यक" सुविधा के बजाय "अच्छा होना" सुविधा के पक्ष में अधिक है, लेकिन फिर टाइपस्क्रिप्ट की कई विशेषताओं के लिए भी यही कहा जा सकता है।

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

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

एक डेवलपर के रूप में मेरे पास कई टोपियाँ हैं; इस समय मेरे पास एक C# हैट, एक कोटलिन हैट और एक टाइपस्क्रिप्ट हैट है।

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

दिलचस्प बात यह है कि जब टाइपस्क्रिप्ट टीम एक मेज के चारों ओर बैठी और abstract कक्षाओं पर चर्चा की, तो क्या किसी ने हाथ उठाया और कहा "लेकिन final बारे में क्या?"

@RyanCavanaugh हम मैं आपकी बातों को समझता हूं

मुझे लगता है कि ज्यादातर यह एक गलतफहमी थी (मुझे लगता है कि हमने कैसे समझाया)

@ Series0ne सारांश वास्तव में अच्छी तरह से है कि हमारे इरादे जेएस में अंतिम वर्ग बनाने के लिए टाइपस्क्रिप्ट आउटपुट को बहुत जटिल नहीं करते थे (बिल्ली ऐसा करने के लिए यह एक ट्रेन मलबे होगा) लेकिन लोगों को बताने के लिए अतिरिक्त नियम बनाने के लिए: नहीं, आप कर सकते हैं ' ऐसा मत करो। और यह एपीआई के उपयोगकर्ता को बताता है कि उन्हें शायद उन वर्ग (स्थिरता, सुरक्षा कारण आदि के लिए) के साथ गड़बड़ नहीं करना चाहिए, सभी टाइपस्क्रिप्ट फाइलों/कंपाइलर पर आउटपुट पर नहीं।

क्या मुझे लगता है कि यह सुविधा होना अच्छा होगा: हाँ, कुछ तकनीक करने का अधिक तेज़ तरीका होना अच्छा है।

क्या इसकी वाकई जरूरत है? वास्तव में यह कुछ मामूली नहीं हो सकता है और प्राथमिकता नहीं होनी चाहिए यदि टाइपस्क्रिप्ट टीम इस अतिरिक्त को लागू करने का जोखिम उठा सकती है तो यह अच्छा हो सकता है।

मैं देखता हूं कि अंतिम/मुहरबंद कीवर्ड विशेष रूप से कुछ पहलुओं को जटिल बना सकता है: बग फिक्स, पैच, व्यवहार में परिवर्तन।

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

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

इसके बाद बस मैं अभी खुद को स्थितियों को गलत समझ सकता हूं इसलिए मुझे इसे समझाने के लिए स्वतंत्र रहें :)

आह अगर मुझे याद है कि मैं ES4 के बारे में बहुत कुछ पढ़ रहा था (मुझे यकीन नहीं है कि मैं अभी भी एक बच्चा था जब मसौदा प्रस्तुतियों में था) और आश्चर्यजनक रूप से यह वास्तव में टाइपस्क्रिप्ट के समान दिखता है।

और यह यहाँ मसौदे विनिर्देशों में कहा गया है:
https://www.ecma-international.org/activities/Languages/Language%20overview.pdf

A class that does not explicitly extend any other class is said to extend the class Object. As a consequence, all the classes that exist form an inheritance hierarchy that is a tree, the root of which is Object. A class designated as final cannot be extended, and final methods cannot be overridden: class C { final function f(n) { return n*2 } } final class D extends C { function g() { return 37 } }

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

मेरे पास एक उपयोग का मामला है कि मैं बस मुश्किल से भाग गया जिसने मुझे इस मुद्दे को खोजने के लिए प्रेरित किया। यह वापसी प्रकार के रूप में this के उपयोग के इर्द-गिर्द घूमता है:

abstract class TileEntity {
    //constructor, other methods...
    abstract cloneAt(x: number, y: number): this;
}

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

class TurretTileEntity extends TileEntity {
    //constructor, other methods...
    cloneAt(x: number, y: number): this {
        return new TurretTileEntity(x, y, /* ... other properties */);
    }
}

समस्या यह है कि यह घोषित करने में सक्षम होने के बिना कि _never_ TurretTileEntity का उपवर्ग होगा, this रिटर्न प्रकार को केवल TurretTileEntity प्रकार तक सीमित नहीं किया जा सकता है।

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

दिलचस्पी से बाहर, जब टाइपस्क्रिप्ट टीम एक मेज के चारों ओर बैठी और अमूर्त कक्षाओं पर चर्चा की, तो क्या किसी ने अपना हाथ उठाया और कहा "लेकिन फाइनल के बारे में क्या"?

हां। हर बार जब हम कोई कीवर्ड जोड़ते हैं, "लेकिन फिर हमें यह दूसरा कीवर्ड भी जोड़ना होगा!" इसे जोड़ने के खिलाफ एक मजबूत बिंदु है, क्योंकि हम भाषा को यथासंभव सावधानी से विकसित करना चाहते हैं। वर्ग घोषणाओं पर final इस शिविर में है - यदि हमारे पास final कक्षाएं हैं, तो हमें final विधियों या गुणों की भी "आवश्यकता" होगी। स्कोप रेंगने वाली कोई भी चीज़ अत्यधिक संदेह की दृष्टि से मानी जाती है।

मुझे लगता है कि अंतिम कक्षाएं और विधियां बहुत महत्वपूर्ण हैं। मुझे आशा है कि आप इसे लागू करेंगे।

ध्यान दें कि यह मुद्दा अंतिम/सीलबंद कक्षाओं के बारे में है। अंतिम/मुहरबंद विधियों की ऑफ-विषय चर्चा हुई है जो एक पूरी तरह से अलग अवधारणा है।

mhegazy ने इस मुद्दे के पक्ष में https://github.com/Microsoft/TypeScript/issues/9264 बंद कर दिया। क्या कोई अलग मुद्दा है जो अंतिम/मुहरबंद विधियों को ट्रैक करने के लिए डुप्ली के रूप में बंद नहीं है?

@crcla ऊपर @RyanCavanaugh की कुछ टिप्पणियों को पढ़ने से, मेरा मानना ​​​​है कि अन्य मुद्दे को बंद करने का तर्क यह है कि अंतिम/सीलबंद कक्षाओं का समर्थन करने में अंतिम/सीलबंद विधियों का समर्थन शामिल है। दोनों काफी निकट से संबंधित विषय हैं।

मैं के लिए प्रस्ताव विश्वास नहीं कर सकता final के रूप में चिह्नित किया गया है Won't fix ।

लेबल को वापस In Discussion बदलें और इसे लागू करें, कृपया!

मेरे मामले में, मैं प्लगइन्स के लिए एक सार बेस क्लास लिखना चाहता हूं और मैं यह सुनिश्चित करना चाहता हूं कि प्लगइन क्लास गलती से मेरी बेस क्लास विधियों को ओवरराइट नहीं कर सकता है। कोई भी private constructor , Object.seal यह काम नहीं कर सकता।

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

अब डाउनवोट्स लाएं

क्या कोई मुझे समझा सकता है कि यह चर्चा अंतिम कक्षाओं और अंतिम विधियों के बीच कैसे भिन्न नहीं है? बेशक कुछ तरीकों को ओवरराइड करने से रोकना बहुत अधिक मूल्य जोड़ता है। मैं एक प्लगइन डेवलपर के लिए अपने कुछ ढांचे वर्गों को उप-वर्गीकृत करके और अमूर्त कार्यों को लागू करके कार्यक्षमता जोड़ने की संभावना प्रदान करना चाहता हूं - लेकिन साथ ही सुनिश्चित करें कि वह इन अमूर्त कार्यों को कॉल करने वाली विधियों को ओवरराइड नहीं करती है (और क्यों!) सुनिश्चित करें कि त्रुटि प्रबंधन/लॉगिन/जांच होती है।

@pelotom यदि आप
दूसरों को एक विशिष्ट (गैर-ओओपी) पैटर्न अपनाने के लिए मजबूर करके, आप वही व्यवहार अपना रहे हैं जिसके लिए आप ओओपी की निंदा करते हैं। कम से कम सुसंगत रहें :)

टाइपस्क्रिप्ट में final कीवर्ड जोड़ना कोई ब्रेकिंग परिवर्तन नहीं है और यह आपके किसी भी मौजूदा प्रोजेक्ट को किसी भी तरह से प्रभावित नहीं करेगा, हालांकि यह @thorek , मेरे और कई अन्य लोगों जैसे लोगों के लिए एक महत्वपूर्ण विशेषता होगी।

अगर कोई ओओपी संरचनाओं का उपयोग करना चाहता है, तो बस उन्हें करने दें।

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

fwiw, हम शायद अपने ग्राहकों (google) को टिप्पणियों में @ final का उपयोग करने के लिए प्रोत्साहित करने जा रहे हैं ताकि यह कंपाइलर को बंद करने के लिए प्रचारित कर सके:\

कक्षाओं और विधियों पर _ final_ जोड़ना तब उपयोगी होता है जब कोई R&D टीम TS लाइब्रेरी बनाती है जिसका उपयोग अन्य टीमें कर सकती हैं। ये खोजशब्द ऐसे उपकरणों की सेवा जोखिम स्थिरता का (एक महत्वपूर्ण) हिस्सा हैं।
बड़ी टीमों के लिए कीवर्ड अधिक महत्वपूर्ण है और छोटी परियोजनाओं के लिए कम महत्वपूर्ण है, इम्हो।

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

मैं इस पर सुधार के लिए खुला हूँ!

मैं अंतिम कक्षाओं की तुलना में अंतिम तरीकों का समर्थन करने के बारे में अधिक परवाह करता हूं (उपवर्गों को गलती से उन्हें ओवरराइड करने से बचने के लिए)। क्या इसके लिए वोट करने का सही टिकट है? टिकट https://github.com/Microsoft/TypeScript/issues/9264 ऐसा प्रतीत होता है।

तो मैं "अंतिम तरीकों" के लिए कैसे वोट करूं? या क्या मैंने सिर्फ इस टिप्पणी से इसे वोट दिया? इसके अलावा हम शीर्षक में "विधियाँ" कैसे जोड़ते हैं? क्या मैं इसे अभी संपादित कर सकता हूँ? वर्तमान शीर्षक भ्रामक रूप से केवल कक्षाओं तक ही सीमित है लेकिन चर्चा में विधियां भी शामिल हैं।

कई अन्य लोगों की तरह मैं टाइपस्क्रिप्ट में अंतिम तरीके देखना चाहूंगा। मैंने आंशिक समाधान के रूप में निम्नलिखित दृष्टिकोण का उपयोग किया है जो विफलता से प्रतिरक्षा नहीं है लेकिन कम से कम थोड़ी मदद करता है:

class parent {
  public get finalMethod(): () => void {
    return () => {
      // final logic
    };
  }
}

class child extends parent {
  // ERROR "Class 'parent' defines instance member accessor 'finalMethod', but extended class 'child' defines it as instance member function"
  public finalMethod(): void { }
}

यहां final विधियों के लिए एक और वास्तविक विश्व उपयोग मामला है। एक साधारण संदर्भ को लागू करना आसान बनाने के लिए React.Component के निम्नलिखित विस्तार पर विचार करें।

interface FooStore{
  foo: string;
}

const {Provider, Consumer} = React.createContext<FooStore>({
  foo: 'bar';
});

abstract class FooConsumerComponent<P, S> extends React.Component<P, S> {

  // implement this instead of render
  public abstract renderWithStore(store: FooStore): JSX.Element;

  public final render() {
    return (
      <Consumer>
        {
          (store) => {
            return this.renderWithStore(store);
          }
        }
      </Consumer>
    );
  }
}

final बिना render() पद्धति पर, कुछ भी गलत तरीके से विधि को ओवरराइड करने से नहीं रोकता है, इस प्रकार सब कुछ तोड़ देता है।

नमस्ते, कई अन्य लोगों की तरह मुझे कम से कम विधियों के लिए "अंतिम" या "मुहरबंद" कीवर्ड चाहिए। मैं पूरी तरह से सहमत हूं कि यह कीवर्ड वास्तव में एक अतिरिक्त मूल्य है क्योंकि यह डेवलपर को अपने पुस्तकालय ग्राहकों को महत्वपूर्ण कोड ब्लॉक (उदाहरण के लिए प्लगइन में) का विस्तार करने से रोकने की अनुमति देता है।

मुझे मिला एकमात्र कामकाज विधि सजावट का उपयोग करना है जैसे:
function sealed(target, key,descriptor){ descriptor.writable = false; // Prevent method to be overriden }

फिर अपने "आधार" वर्ग में, विधि ओवरराइड को रोकने के लिए डेकोरेटर का उपयोग करें, उदाहरण:

class MyBaseClass {
<strong i="10">@sealed</strong>
public MySealedMethod(){}

public OtherMethod(){}

...
}

इस तरह 'MySealedMethod' उप वर्ग में (आसानी से) ओवरराइड नहीं हो सका। उदाहरण:

class AnotherClass extends MyBaseClass {
public MySealedMethod(){} ====>> ERROR at RUNTIME (not at compile time)
}

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

@RyanCavanaugh

हां। हर बार जब हम कोई कीवर्ड जोड़ते हैं, "लेकिन फिर हमें यह दूसरा कीवर्ड भी जोड़ना होगा!" इसे जोड़ने के खिलाफ एक मजबूत बिंदु है, क्योंकि हम भाषा को यथासंभव सावधानी से विकसित करना चाहते हैं।

मुझे ऐसा लगता है कि आप इस तर्क को फीचर के खिलाफ अपने दिमाग से शुरू कर रहे हैं। एक लोकप्रिय विशेषता ऐसी सुविधा पर विचार करने के खिलाफ एक बिंदु नहीं होना चाहिए। यह अपने आप से पूछने की दिशा में एक बिंदु होना चाहिए _यह लोकप्रिय क्यों है_, और फिर ध्यान से इस पर विचार करें।

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

मैं इन प्रश्नों को यहां हम सभी के विचार के लिए छोड़ देता हूं।

क्या वर्तमान संरचनाओं का उपयोग करके _by design_ कक्षा को सील करने का कोई तरीका है?
यदि यह सुविधा जोड़ी जाती, तो क्या यह हमें कुछ नया करने की अनुमति देती? (जैसा कि, कुछ वर्तमान निर्माण की अनुमति नहीं है)
यदि सुविधा ने हमें कुछ नया करने की अनुमति दी है, तो क्या यह कुछ मूल्यवान है?
क्या सीलबंद कक्षाओं को जोड़ने से भाषा की जटिलता बहुत अधिक बढ़ जाएगी?
क्या सीलबंद कक्षाओं को जोड़ने से संकलक जटिलता बहुत अधिक बढ़ जाएगी?

इन पर चर्चा करने के उद्देश्य से, मैं चर्चा में सीलबंद विधियों को शामिल नहीं कर रहा हूं और मैं कार्यान्वयन में रन-टाइम चेक भी शामिल नहीं कर रहा हूं। हम सभी समझते हैं कि हम इसे Javascript पर लागू नहीं कर सकते हैं।

एफवाईआई: अगर इस सुविधा का काउंटर फीचर-रेंगना के खिलाफ सिर्फ कंबल बयान से थोड़ा अधिक था तो मुझे बहुत अच्छा लगेगा।

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

यहाँ हमारे मन को क्या बदलेगा? कोड के उदाहरणों के साथ दिखाई देने वाले लोग

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

टाइपस्क्रिप्ट में यह कीवर्ड क्यों होना चाहिए जब स्थिति पहले से ही एक है जिसमें आपको कम से कम दो अलग-अलग बाधाओं का सामना करना चाहिए था जो आपको बता रहे थे कि शुरू करने के लिए वहां नहीं होना चाहिए?

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

एक वास्तविक मामला जो मैं अंतिम उपयोग कर रहा हूं वह किसी विधि को ओवरराइड करने से रोकना है जो कभी भी सुपर विधि को कॉल नहीं करेगा। बेशक कुछ सार्वजनिक तरीका। लेकिन मुझे लगा कि असली समाधान सुपर को कॉल करने के लिए किसी भी उप विधि को मजबूर करने की क्षमता होगी। https://github.com/Microsoft/TypeScript/issues/21388

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

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

बहस में अपना थोड़ा सा जोड़ने के लिए, मैं अपना अंगूठा पैमाने के हां-पक्ष पर रखना चाहता हूं क्योंकि यह मुद्दा फीचर को जोड़ने के समर्थन में अच्छे तर्कों से भरा हुआ है, फिर भी मैं इसके खिलाफ तर्क देख रहा हूं:

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

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

आशा है कि यह रचनात्मक है! टीएस से प्यार करें और इसे सुधारते हुए देखना चाहते हैं!

मैं

--संपादित करें--

@RyanCavanaugh के जवाब में:

So what problem is being solved?

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

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

हाल की अधिकांश चर्चा अंतिम विधियों (अंतिम कक्षाओं पर कम) पर केंद्रित रही है। अंतिम तरीके निश्चित रूप से मेरी प्राथमिक रुचि हैं। मैंने अभी देखा है कि यदि आप @RyanCavanaugh की पिछली पोस्ट में "इस टिप्पणी" लिंक का विस्तार करते हैं तो वह अंतिम विधि चर्चा ऑफ-विषय पर विचार करता है। हालाँकि @mhegazy ने सुझाव दिया कि यह टिकट सही जगह है (#9264 बंद करते समय)। इसलिए एक नीच अंत उपयोगकर्ता के रूप में मैं इस बात से चकित हूं कि मुझे अंतिम तरीकों के लिए कहां से पूछना चाहिए/मतदान करना चाहिए। मार्गदर्शन की सराहना की जाएगी।

@cbutterfield
विरोधाभास कुछ ऐसा है जिस पर मैंने ध्यान दिया, लेकिन शेख़ी के डर से अपनी पोस्ट में इंगित नहीं किया (मुझे वास्तव में यह धागा #9264 के माध्यम से मिला और यहां
@RyanCavanaugh
@mhegazy
उपरोक्त टिप्पणी के अनुसार, जहां _is_ अंतिम तरीकों पर चर्चा करने के लिए सही जगह है, क्योंकि वास्तव में यही वह चीज है जिसमें मुझे सबसे ज्यादा दिलचस्पी है।

मेरी भारी अस्वीकृत टिप्पणी पर पीछे मुड़कर देखें (सुनिश्चित करें कि यदि आपने अभी तक नहीं किया है तो अपना जोड़ें!) मुझे यह रिपोर्ट करते हुए खुशी हो रही है कि रिएक्ट _no long_ एक class -आधारित API को बाध्य करके एक बुरा उदाहरण स्थापित कर रहा है। अपने उपयोगकर्ताओं पर! हुक के प्रस्ताव के साथ, रिएक्ट टीम अपने होश में आ गई है और एक मौलिक रूप से सरल कार्यात्मक दृष्टिकोण अपनाया है। इसके साथ, कई डेवलपर्स के लिए कक्षाओं का उपयोग करने का आखिरी कारण वाष्पित हो गया है, और अच्छी छुटकारा है। मैं फिर से दोहराऊंगा: जो कुछ भी आपको लगता है कि आपको कक्षाओं की आवश्यकता है, उनके बिना बेहतर तरीके से किया जा सकता है ।

जेएस और टीएस का भविष्य वर्गहीन है, प्रशंसा हो!

@cbutterfield मैंने उस पर भी ध्यान दिया, और अगर इस मुद्दे पर चर्चा करने के लिए मुद्दा #9264 बंद कर दिया गया था, तो मुझे लगता है कि शीर्षक Suggestion: Final keyword for classes and methods बदल जाना चाहिए, अन्यथा अंतिम तरीकों की तलाश करने वाले लोग (विशेष रूप से) प्रतिक्रिया नहीं जोड़ सकते हैं पहली पोस्ट।

@mhegazy का हवाला देते हुए :
जावा और/या सी# रनटाइम पर आपकी कक्षा को अनुकूलित करने के लिए final वर्ग का उपयोग करता है, यह जानते हुए कि यह विशिष्ट नहीं होगा। यह मैं तर्क दूंगा कि अंतिम समर्थन के लिए मुख्य मूल्य है। टाइपस्क्रिप्ट में ऐसा कुछ भी नहीं है जो हम आपके कोड को बिना फाइनल के चलाने से बेहतर बनाने की पेशकश कर सकते हैं।

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

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

हालांकि यह समस्या लगभग 3 वर्ष पुरानी है, हमारे पास वास्तव में final कीवर्ड होना चाहिए क्योंकि पहले से ही एक abstract कीवर्ड है।

ध्यान रखें कि हम लोगों को इसका उपयोग करने के लिए मजबूर नहीं करना चाहते हैं और यह एक विशेषता है जो अमूर्त कीवर्ड की तरह उपयोगी है। लेकिन यहां एक और उपयोग मामला है जो final कीवर्ड के लाभ को दृढ़ता से दिखाएगा:

abstract class A {
  protected abstract myVar: string;

  protected abstract myFunction(): void;
}

class B extends A {
  protected readonly myVar: string = "toto";

  constructor() {
    super();
    this.myFunction();
  }

  protected myFunction() {
    console.log(this.myVar);
  }
}

class C extends B {
  constructor() {
    super();
  }

  protected myFunction() {
    console.log("tata");
  };

  public callFunction = () => {
    this.myFunction();
  }
}

const myB = new B(); // toto

const myC = new C(); // toto
myC.callFunction(); // tata

संकलन के बाद परिणाम:

toto
tata

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

तो क्या हुआ अगर हम टाइपस्क्रिप्ट संकलन प्रक्रिया में आगे बढ़ते हैं और अपनी विशेषताओं की रक्षा के लिए readonly का उपयोग करते हैं (और दिखावा करते हैं कि हमारे तरीके गुण हैं)?

class B extends A {
  [...]

  protected readonly myFunction = () => {
    console.log(this.myVar);
  }
}

class C extends B {
  protected myVar: string = "I am not protected that much";
  [...]

  protected myFunction = () => { // using the readonly keyword doesn't prevent any modification
    console.log("tata"); // If you launch this code, tata will still be logged in the console.
  };
}

(ध्यान दें कि कोड tsc के साथ संकलित किया गया है, इसे संकलित या निष्पादित करते समय कोई त्रुटि नहीं हुई है)
तो अब हमें दो समस्याएं हैं:

• हम अपनी B विशेषताओं की रक्षा नहीं करते हैं, इसलिए हमें किसी भी अप्रत्याशित विरासत को रोकने के लिए एक तरीके की आवश्यकता है।
• अब हम जानते हैं कि हम किसी भी ओवरराइड कर सकते हैं readonly , अपने वर्ग का विस्तार करके गुण और हाँ, टाइपप्रति जानता है कि यह मूल प्रॉपर्टी हम प्रयोग कर के रूप में बदल रहे हैं है private के बजाय protected C वर्ग में एक त्रुटि होगी क्योंकि यह समान पहुंच प्रकार/दृश्यता नहीं है।

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

मैं देखूंगा कि क्या "सुरक्षा उल्लंघन" के बारे में कोई समस्या है (यदि हम इसे कॉल कर सकते हैं) जब हम एक संरक्षित रीडोनली मान को ओवरराइड करना चाहते हैं और हम वास्तव में कर सकते हैं और हमें नहीं करना चाहिए। अन्यथा मैं readonly कीवर्ड के सत्यापन पर बहस के लिए एक मुद्दा खोलूंगा private , protected इनहेरिटेंस सामान के साथ कीवर्ड।

टीएल; डॉ : final कीवर्ड दो समस्याओं का समाधान करेगा (हालांकि readonly सत्यापन किसी भी अनधिकृत पुनर्लेखन को रोकने के लिए एक अच्छी शुरुआत होगी)

तीन साल बाद ... यह कितना हास्यास्पद है।

इस सुविधा की आवश्यकता को साबित करने के लिए, मेरा सुझाव है कि अन्य भाषाओं में क्या किया गया, इस पर एक नज़र डालें:

Java:
final class SomeClass { ... }
PHP:
final class SomeClass { ... }
C#:
sealed class SomeClass {...}
C++:
class SomeClass final { ... }
Delphi:
type SomeClass = class sealed() ... end;

इसलिए, हम देखते हैं कि सभी सबसे लोकप्रिय ओओपी भाषाओं में यह सुविधा मौजूद है क्योंकि यह ओओपी के वंशानुक्रम तर्क से आती है।

इसके अलावा मुझे टीएस के देव नेतृत्व को यह कहते हुए उद्धृत करना होगा

यदि हमारे पास अंतिम कक्षाएं हैं, तो हमें अंतिम विधियों या गुणों की भी "आवश्यकता" होगी।

मुझे यकीन नहीं है कि यह विडंबनापूर्ण है, लेकिन जेएस में केवल पढ़ने योग्य कीवर्ड गुणों के लिए उपयोग किया जाता है (और यदि आप धोखा देते हैं तो विधियां), तो यह एक सुंदर गूंगा बिंदु है।

और हो सकता है कि एक व्यक्ति को +40 डाउनवोट होने पर इस मुद्दे को बंद न करने दें, जिसका अर्थ है कि समुदाय उसके साथ दृढ़ता से असहमत है, आगे की गूंगा स्थितियों से बचने के लिए एक अच्छी सलाह होगी।

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

हो सकता है कि एक व्यक्ति को +40 डाउनवोट होने पर इस मुद्दे को बंद न करने दें, जिसका अर्थ है कि समुदाय उसके साथ दृढ़ता से असहमत है, आगे की गूंगा स्थितियों से बचने के लिए एक अच्छी सलाह होगी

मैं "एक आदमी" नहीं हूँ। जब मैं यहां निर्णय लेता हूं, तो यह संपूर्ण टाइपस्क्रिप्ट टीम की निर्णय लेने की प्रक्रिया का प्रतिबिंब होता है। डिज़ाइन टीम ने इस मुद्दे को कई बार देखा है, और हर बार एक ही निष्कर्ष पर आते हैं। उस परिणाम से असहमत होने के लिए आपका स्वागत है, लेकिन प्रक्रिया बहस के लिए तैयार नहीं है।

आपके पास समुदाय को यह मान्य करने की कोई प्रक्रिया नहीं है कि हमें क्या चाहिए या नहीं।

यह प्रक्रिया, यहीं है: आप हमारे तर्क की मेरी संक्षिप्तीकरण "गूंगा" बुला और मुझे (और टीम पर अन्य लोगों) इसे पढ़ने के। हम प्रतिक्रिया सुन रहे हैं।

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

अंत में, मैं ऐसी सुविधा के बिना रह सकता हूं, लेकिन टीएस की लगभग आधी सुविधाओं के लिए भी यही कहा जा सकता है। तो फिर, इसे लागू करने पर विचार करने का उचित कारण क्या होगा?

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

पिछली बार जब हमने इसकी समीक्षा की थी तब कुछ बिंदुओं पर विचार किया गया था

• कक्षाएं एक जावास्क्रिप्ट सुविधा हैं, टाइपस्क्रिप्ट सुविधा नहीं । यदि आप वास्तव में ऐसा महसूस करते हैं कि final बिना कक्षाएं पूरी तरह से बेकार हैं, तो यह TC39 समिति के साथ उठाने या es-चर्चा करने के लिए कुछ है। यदि कोई भी TC39 को यह समझाने के लिए तैयार या सक्षम नहीं है कि final एक अनिवार्य विशेषता है, तो हम इसे टाइपस्क्रिप्ट में जोड़ने पर विचार कर सकते हैं।
• यदि किसी चीज़ पर new का आह्वान करना कानूनी है, तो इससे विरासत में मिलने वाला एक-से-एक रनटाइम पत्राचार है। किसी ऐसी चीज़ की धारणा जो new 'd हो सकती है लेकिन super 'd नहीं हो सकती है, जावास्क्रिप्ट में मौजूद नहीं है
• हम टाइपस्क्रिप्ट को OOP कीवर्ड सूप में बदलने से बचने की पूरी कोशिश कर रहे हैं। जावास्क्रिप्ट में विरासत की तुलना में कई बेहतर रचना यांत्रिकी हैं और हमें सी # और जावा के हर एक कीवर्ड की आवश्यकता नहीं है।
• आप "चाहिए-अंतिम" वर्ग से विरासत का पता लगाने के लिए एक रनटाइम चेक को तुच्छ रूप से लिख सकते हैं, जिसे आपको वास्तव में वैसे भी करना चाहिए यदि आप किसी ऐसे व्यक्ति के बारे में "चिंतित" हैं जो गलती से आपकी कक्षा से विरासत में मिला है क्योंकि आपके सभी उपभोक्ता टाइपस्क्रिप्ट का उपयोग नहीं कर रहे हैं .
• आप एक शैलीगत सम्मेलन को लागू करने के लिए एक लिंट नियम लिख सकते हैं जो कुछ वर्गों से विरासत में नहीं मिला है
• परिदृश्य है कि किसी को "गलती से" आपके द्वारा सील की जाने वाली कक्षा से विरासत में मिला होगा, एक अजीब तरह का है। मैं यह भी तर्क दूंगा कि किसी व्यक्ति का व्यक्तिगत मूल्यांकन किसी दिए गए वर्ग से प्राप्त करने के लिए "संभव" है या नहीं, शायद यह संदिग्ध है।
• किसी वर्ग को सील करने के मूल रूप से तीन कारण हैं: सुरक्षा, प्रदर्शन और आशय। उनमें से दो टाइपस्क्रिप्ट में कोई मतलब नहीं रखते हैं, इसलिए हमें किसी ऐसी चीज की जटिलता बनाम लाभ पर विचार करना होगा जो अन्य रनटाइम में केवल 1/3 काम कर रही है।

टीएस को इसकी आवश्यकता क्यों नहीं है, इसके लिए एक ठोस तर्क नहीं सुना है

बस एक अनुस्मारक कि यह कैसे काम नहीं करता है। सभी सुविधाएं -100 से शुरू होती हैं । उस पोस्ट से

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

हमारे पास एक सीमित जटिलता बजट है। हम जो कुछ भी करते हैं वह हर अगले काम को 0.1% धीमा कर देता है। जब आप किसी सुविधा का अनुरोध करते हैं, तो आप अनुरोध कर रहे हैं कि हर दूसरी सुविधा थोड़ी कठिन, थोड़ी धीमी, थोड़ी कम संभव हो जाए। यहां दरवाजे में कुछ भी नहीं मिलता है क्योंकि जावा के पास है या क्योंकि सी # के पास है या क्योंकि यह केवल कोड की कुछ पंक्तियां होगी या आप कमांडलाइन स्विच जोड़ सकते हैं । सुविधाओं को अपने लिए और भविष्य पर उनके पूरे बोझ के लिए भुगतान करना होगा।

यहाँ हमारे मन को क्या बदलेगा? कोड के उदाहरणों के साथ दिखाई देने वाले लोग

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

दूसरे शब्दों में: जावास्क्रिप्ट में किसी वर्ग से विरासत में प्राप्त करने की एकमात्र सही प्रक्रिया हमेशा उस वर्ग के दस्तावेज़ीकरण को पढ़ने से शुरू होती है । बेस क्लास को केवल कोडिंग शुरू करने और शुरू करने के लिए बहुत सी बाधाएं हैं। यदि, पहले चरण में , आपको पहले से ही पता होना चाहिए कि कोशिश नहीं करनी है, तो चरण तीन में स्थिर प्रवर्तन क्या मूल्य प्रदान कर रहा है?

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

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

यदि आप टाइपस्क्रिप्ट की मुख्य विशेषता को सुदृढ़ करने में रुचि नहीं रखते हैं, तो कृपया इसे ज़ोर से कहें ताकि तकनीकी समाचार ट्विटर पर प्रसारित कर सकें

हम इस बारे में बहुत स्पष्ट हैं कि हम भाषा को कैसे डिज़ाइन करते हैं ; गैर-गोल नंबर एक इस सुझाव के लिए बिल्कुल सही बोलता है।

यहां कई टिप्पणियों को पढ़ने के बाद मेरी व्यक्तिगत प्रतिक्रिया यह है कि अन्य भाषाओं में मौजूद निर्माणों के कारण एक मजबूत पूर्वाग्रह प्रभाव पड़ता है। यदि आप इसे रिक्त स्लेट के दृष्टिकोण से देखते हैं, तो ऐसे दर्जनों व्यवहार हैं जिनकी आप कल्पना कर सकते हैं, जिनमें से टाइपस्क्रिप्ट का केवल एक छोटा उपसमुच्चय है।

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

तो फिर, इसे लागू करने पर विचार करने का उचित कारण क्या होगा?

जब हम फीडबैक देखते हैं, तो मजबूत विचार इस तरह दिखते हैं:

• मैं इस जावास्क्रिप्ट पुस्तकालय के व्यवहार को पर्याप्त रूप से व्यक्त नहीं कर सकता
• मेरा कोड संकलित है, लेकिन वास्तव में ऐसा नहीं होना चाहिए क्योंकि इसमें यह (सूक्ष्म) त्रुटि थी
• इस कोड का आशय टाइप सिस्टम द्वारा पर्याप्त रूप से संप्रेषित नहीं किया गया है

final इन्हें हिट करता है, लेकिन ऐसा एक संशोधक होगा जो कहता है कि "इस फ़ंक्शन को लगातार दो बार नहीं कहा जा सकता है" या "इस वर्ग का निर्माण वास्तव में अगले async टिक तक समाप्त नहीं होता है"। कल्पना की जाने वाली हर चीज मौजूद नहीं होनी चाहिए।

हमने कभी भी फीडबैक नहीं देखा है जैसे "मैंने घंटों डिबगिंग का समय बिताया क्योंकि मैं उस वर्ग से विरासत में लेने की कोशिश कर रहा था जो वास्तव में उप-वर्गीय नहीं था" - कोई कह रहा है कि यह 'वाट' को सही ढंग से ट्रिगर करेगा क्योंकि यह वास्तव में कल्पना करने योग्य नहीं है। यहां तक ​​​​कि अगर संशोधक मौजूद है, तो यह वास्तव में स्थिति fs.FSwatcher final ? ऐसा लगता है जैसे नोड लेखक भी नहीं जानते। तो final पर्याप्त है यदि लेखकों को पता है कि यह final , लेकिन यह परवाह किए बिना दस्तावेज होने जा रहा है, और final की कमी वास्तव में आपको कुछ भी नहीं बताती है क्योंकि यह अक्सर होता है बस किसी भी तरह से नहीं जाना जाता है।

मैं पूरे खंड को पढ़ता हूं और सुविधाओं के चुनाव पर टीम के बयान को समझता हूं, मैं अपनी टिप्पणियों से कुछ बिंदुओं पर वापस जाऊंगा

मैं "एक आदमी" नहीं हूँ। जब मैं यहां निर्णय लेता हूं, तो यह संपूर्ण टाइपस्क्रिप्ट टीम की निर्णय लेने की प्रक्रिया का प्रतिबिंब होता है।

क्षमा करें, मैं मेगाज़ी का उल्लेख कर रहा था और टाइपस्क्रिप्ट का उपयोग करने वाले समुदाय से उसे बहुत बड़ी प्रतिक्रिया मिली।

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

मुझे नहीं लगता कि final पहला कदम है क्योंकि private कीवर्ड के लिए पहले से ही एक प्रस्ताव है https://github.com/tc39/proposal-private-methods

मुझे You should a comment to say *dont do this* बारे में संदेह है, यह एक फॉर्म Hey don't write down specific characters पर कहने जैसा है, आपने लगभग हमेशा के लिए कोड किया है, इसलिए आपको एक देव के n ° 1 नियम को जानना चाहिए: उपयोगकर्ता पर कभी भरोसा न करें ( और वह देव जो आपके कोड का उपयोग करेगा)

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

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

आपने उन्हें लागू करने के लिए निजी/सार्वजनिक तरीकों के लिए JS की प्रतीक्षा नहीं की, हालांकि वास्तव में उन्हें # कीवर्ड ( public / private से कम वर्बोज़) के साथ शामिल करने के प्रस्ताव हैं। ), मुझे पता है कि आप एक संपूर्ण भाषा बनाना चाहते थे क्योंकि पूर्णता तब नहीं है जब आप कुछ और नहीं जोड़ सकते हैं, यह तब है जब आप अब और कुछ भी नहीं हटा सकते हैं।

यदि आप संकलन प्रक्रिया में किसी विधि को अधिलेखित करने से रोकने के लिए कोई समाधान ढूंढ सकते हैं (और रनटाइम-प्रक्रिया में नहीं क्योंकि बिंदु मान्य नहीं होगा), मेरे अतिथि बनें।

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

वैसे उत्तर के लिए धन्यवाद, देव टीम या आपके खिलाफ कोई नफरत या बुरा व्यवहार नहीं है।

सभी मान्य बिंदु! लेकिन, कृपया चर्चा को बीच में बांट दें

ए) अंतिम कक्षाओं का समर्थन करें
बी) अंतिम तरीकों का समर्थन करें

जबकि आपके सभी तर्क a) को लक्षित करते हैं - कोई भी लक्ष्य b नहीं।

अंतिम विधियों का होना महत्वपूर्ण है जैसा कि कई बार चर्चा में बताया गया था। मैंने अब तक केवल यही उत्तर सुना है कि "ओओपी मत करो" - लेकिन ऐसा कुछ भी नहीं है जिसे मैं (और कई अन्य) साथ ले जाऊंगा।

एएम 28.01.2019 उम 20:32 स्क्रिब रयान कैवानॉघ नोटिफिकेशन @github.com:

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

पिछली बार जब हमने इसकी समीक्षा की थी तब कुछ बिंदुओं पर विचार किया गया था

कक्षाएं एक जावास्क्रिप्ट सुविधा हैं, टाइपस्क्रिप्ट सुविधा नहीं। यदि आप वास्तव में ऐसा महसूस करते हैं कि फाइनल के बिना कक्षाएं पूरी तरह से बेकार हैं, तो यह कुछ ऐसा है जिसे TC39 समिति के साथ उठाया जाना चाहिए या इस पर चर्चा करनी चाहिए। यदि कोई भी TC39 को यह समझाने के लिए तैयार या सक्षम नहीं है कि फाइनल एक अनिवार्य विशेषता है, तो हम इसे टाइपस्क्रिप्ट में जोड़ने पर विचार कर सकते हैं।
यदि किसी चीज़ पर नया आह्वान करना कानूनी है, तो इससे विरासत में मिलने वाला एक-से-एक रनटाइम पत्राचार है। किसी ऐसी चीज़ की धारणा जो नई हो सकती है लेकिन सुपर नहीं हो सकती है, जावास्क्रिप्ट में मौजूद नहीं है
हम टाइपस्क्रिप्ट को OOP कीवर्ड सूप में बदलने से बचने की पूरी कोशिश कर रहे हैं। जावास्क्रिप्ट में विरासत की तुलना में कई बेहतर रचना यांत्रिकी हैं और हमें सी # और जावा के हर एक कीवर्ड की आवश्यकता नहीं है।
आप "चाहिए-अंतिम" वर्ग से विरासत का पता लगाने के लिए एक रनटाइम चेक को तुच्छ रूप से लिख सकते हैं, जिसे आपको वास्तव में वैसे भी करना चाहिए यदि आप किसी ऐसे व्यक्ति के बारे में "चिंतित" हैं जो गलती से आपकी कक्षा से विरासत में मिला है क्योंकि आपके सभी उपभोक्ता टाइपस्क्रिप्ट का उपयोग नहीं कर रहे हैं .
आप एक शैलीगत सम्मेलन को लागू करने के लिए एक लिंट नियम लिख सकते हैं जो कुछ वर्गों से विरासत में नहीं मिला है
परिदृश्य है कि किसी को "गलती से" आपके द्वारा सील की जाने वाली कक्षा से विरासत में मिला होगा, एक अजीब तरह का है। मैं यह भी तर्क दूंगा कि किसी व्यक्ति का व्यक्तिगत मूल्यांकन किसी दिए गए वर्ग से प्राप्त करने के लिए "संभव" है या नहीं, शायद यह संदिग्ध है।
किसी वर्ग को सील करने के मूल रूप से तीन कारण हैं: सुरक्षा, प्रदर्शन और आशय। उनमें से दो टाइपस्क्रिप्ट में कोई मतलब नहीं रखते हैं, इसलिए हमें किसी ऐसी चीज की जटिलता बनाम लाभ पर विचार करना होगा जो अन्य रनटाइम में केवल 1/3 काम कर रही है।
टीएस को इसकी आवश्यकता क्यों नहीं है, इसके लिए एक ठोस तर्क नहीं सुना है

बस एक अनुस्मारक कि यह कैसे काम नहीं करता है। सभी सुविधाएं -100 https://blogs.msdn.microsoft.com/ericgu/2004/01/12/minus-100-points/ से शुरू होती हैं। उस पोस्ट से

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

हमारे पास एक सीमित जटिलता बजट है। हम जो कुछ भी करते हैं वह हर अगले काम को 0.1% धीमा कर देता है। जब आप किसी सुविधा का अनुरोध करते हैं, तो आप अनुरोध कर रहे हैं कि हर दूसरी सुविधा थोड़ी कठिन, थोड़ी धीमी, थोड़ी कम संभव हो जाए। यहां दरवाजे में कुछ भी नहीं मिलता है क्योंकि जावा के पास है या क्योंकि सी # के पास है या क्योंकि यह केवल कोड की कुछ पंक्तियां होगी या आप कमांडलाइन स्विच जोड़ सकते हैं। सुविधाओं को अपने लिए और भविष्य पर उनके पूरे बोझ के लिए भुगतान करना होगा।

यहाँ हमारे मन को क्या बदलेगा? लोग कोड के उदाहरण दिखा रहे हैं जो उस तरह से काम नहीं कर रहा था जैसा उसे होना चाहिए था क्योंकि अंतिम कीवर्ड गायब था।

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

दूसरे शब्दों में: जावास्क्रिप्ट में किसी वर्ग से विरासत में प्राप्त करने की एकमात्र सही प्रक्रिया हमेशा उस वर्ग के दस्तावेज़ों को पढ़ने से शुरू होती है। बेस क्लास को केवल कोडिंग शुरू करने और शुरू करने के लिए बहुत सी बाधाएं हैं। यदि, पहले चरण में, आपको पहले से ही पता होना चाहिए कि प्रयास नहीं करना है, तो चरण तीन में स्थिर प्रवर्तन क्या मूल्य प्रदान कर रहा है?

टाइपस्क्रिप्ट में यह कीवर्ड क्यों होना चाहिए जब स्थिति पहले से ही एक है जिसमें आपको कम से कम दो अलग-अलग बाधाओं का सामना करना चाहिए था जो आपको बता रहे थे कि शुरू करने के लिए वहां नहीं होना चाहिए?

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

यदि आप टाइपस्क्रिप्ट की मुख्य विशेषता को सुदृढ़ करने में रुचि नहीं रखते हैं, तो कृपया इसे ज़ोर से कहें ताकि तकनीकी समाचार ट्विटर पर प्रसारित कर सकें

हम इस बारे में बहुत स्पष्ट हैं कि हम भाषा कैसे डिज़ाइन करते हैं https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals ; गैर-गोल नंबर एक इस सुझाव के लिए बिल्कुल सही बोलता है।

यहां कई टिप्पणियों को पढ़ने के बाद मेरी व्यक्तिगत प्रतिक्रिया यह है कि अन्य भाषाओं में मौजूद निर्माणों के कारण एक मजबूत पूर्वाग्रह प्रभाव पड़ता है। यदि आप इसे रिक्त स्लेट के दृष्टिकोण से देखते हैं, तो ऐसे दर्जनों व्यवहार हैं जिनकी आप कल्पना कर सकते हैं, जिनमें से टाइपस्क्रिप्ट का केवल एक छोटा उपसमुच्चय है।

आप आसानी से कुछ कीवर्ड की कल्पना कर सकते हैं जो एक विधि पर लागू किया गया था और उस व्युत्पन्न विधियों को सुपर https://github.com/Microsoft/TypeScript/issues/21388 के माध्यम से लागू किया गया था। यदि C# और Java में यह कीवर्ड होता, तो लोग उस कीवर्ड को उन जगहों पर पूरी तरह से लागू करते जहां यह समझ में आता। वास्तव में, यह तर्कसंगत रूप से अंतिम से अधिक सामान्य रूप से लागू किया जाएगा, क्योंकि रनटाइम चेक को लागू करना असंभव है, और "व्युत्पन्न कक्षाएं मौजूद नहीं हो सकती" की तुलना में बेस-व्युत्पन्न अनुबंध का एक और अधिक सूक्ष्म पहलू है। यह कई तरह से उपयोगी होगा जो कि final नहीं होगा। मेरे पास उस कीवर्ड की तुलना में बहुत अधिक होगा (हालांकि मुझे लगता है कि न तो जटिलता बनाम मूल्य बार से मिलता है)।

तो फिर, इसे लागू करने पर विचार करने का उचित कारण क्या होगा?

जब हम फीडबैक देखते हैं, तो मजबूत विचार इस तरह दिखते हैं:

मैं इस जावास्क्रिप्ट पुस्तकालय के व्यवहार को पर्याप्त रूप से व्यक्त नहीं कर सकता
मेरा कोड संकलित है, लेकिन वास्तव में ऐसा नहीं होना चाहिए क्योंकि इसमें यह (सूक्ष्म) त्रुटि थी
इस कोड का आशय टाइप सिस्टम द्वारा पर्याप्त रूप से संप्रेषित नहीं किया गया है
final इन्हें हिट करता है, लेकिन ऐसा एक संशोधक होगा जो कहता है कि "इस फ़ंक्शन को एक पंक्ति में दो बार नहीं कहा जा सकता है" या "इस वर्ग का निर्माण वास्तव में अगले async टिक तक समाप्त नहीं होता है"। कल्पना की जाने वाली हर चीज मौजूद नहीं होनी चाहिए।

हमने कभी भी फीडबैक नहीं देखा है जैसे "मैंने घंटों डिबगिंग का समय बिताया क्योंकि मैं उस वर्ग से विरासत में लेने की कोशिश कर रहा था जो वास्तव में उप-वर्गीय नहीं था" - कोई कह रहा है कि यह 'वाट' को सही ढंग से ट्रिगर करेगा क्योंकि यह वास्तव में कल्पना करने योग्य नहीं है। भले ही संशोधक मौजूद हो, यह वास्तव में स्थिति में मदद नहीं करेगा, क्योंकि पुस्तकालय दस्तावेज नहीं करते हैं यदि कक्षाएं अंतिम होने का इरादा है - जैसे fs.FSwatcher https://nodejs.org/api/fs.html#fs_class_fs_fswatcher final ? ऐसा लगता है जैसे नोड लेखक भी नहीं जानते। तो final पर्याप्त है यदि लेखकों को पता है कि यह अंतिम है, लेकिन इसकी परवाह किए बिना प्रलेखित किया जा रहा है, और final की कमी वास्तव में आपको कुछ भी नहीं बताती है क्योंकि यह अक्सर किसी भी तरह से ज्ञात नहीं होता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
सीधे इस ईमेल का जवाब है, यह GitHub पर देखने https://github.com/Microsoft/TypeScript/issues/8306#issuecomment-458268725 , या धागे मूक https://github.com/notifications/unsubscribe-auth/AA3NA4o9wu54CcJyK1C8WHVjXIQwfmsUks5vH1A8gaJpZM4IP8M3 ।

हाँ, चर्चा अब इतनी फैल गई है। मैं इन मुद्दों को एक ट्रैकर में देखना चाहता हूं जहां आप वोट कर सकते हैं, जैसे कि इंटेलिजे/वेबस्टॉर्म मुद्दों के लिए उपयोग किया जाता है। कक्षाओं और/या विधियों के लिए कितने लोग final देखना चाहेंगे, इसकी कुछ वास्तविक संख्याएँ प्राप्त करें।

अंतिम बहुत मददगार होगा

एक अमूर्त कीवर्ड का उपयोग प्रोग्रामर को याद दिलाने के लिए किया जाता है कि उन्हें फ़ील्ड को ओवरराइड करना चाहिए। उन्हें याद दिलाने के लिए एक कीवर्ड इसे ओवरराइड न करने के लिए इसी तरह मददगार होगा।

कोड को अधिक संरचित और/या सुरक्षित बनाने के लिए अंतिम विधियां महत्वपूर्ण हो सकती हैं।

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

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

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

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

मुझे विधियों के लिए final आएगा (और मुझे लगता है कि सामान्य रूप से गुण और घोषणाएं)। यह वास्तविक परेशानी पैदा कर रहा है - लोग गलती से चीजों को ओवरराइड करते रहते हैं, यह महसूस नहीं करते कि नीचे एक था ... सामान तोड़ रहा था ...

मुझे यह भी लगता है कि अंतिम तरीकों का बहुत महत्व होगा, और जैसा कि अन्य ने बताया है, सभी तर्कों के खिलाफ अंतिम कक्षाओं पर ध्यान केंद्रित करना प्रतीत होता है। एक अलग मुद्दा था (#9264) लेकिन इसे बंद कर दिया गया क्योंकि जाहिर तौर पर यह मुद्दा इसे कवर करता है, लेकिन मुझे नहीं लगता कि यह वास्तव में करता है। क्या हम या तो उस मुद्दे को फिर से खोल सकते हैं, या उसे यहाँ ठीक से संबोधित कर सकते हैं?

मेरी स्थिति @ 0815fox के समान है जहां मेरे पास एक विधि का "आंतरिक" संस्करण है, जो सार है, लेकिन मैं चाहता हूं कि विधि का "मूल" संस्करण कभी भी ओवरराइड न हो, क्योंकि इसमें महत्वपूर्ण व्यवहार होता है और मैं नहीं चाहता उस एक को ओवरराइड करने के लिए एक उपवर्ग।

मुझे यह चौंकाने वाला लगता है कि इस सुविधा के पक्ष में समुदाय के भारी समर्थन से कोई फर्क नहीं पड़ता, इसे अभी भी टाइपस्क्रिप्ट डेवलपर्स द्वारा अस्वीकार कर दिया जा रहा है ...

शायद एक स्टॉप गैप टीएस-डॉक के लिए एक मानक जोड़ने के लिए होगा जहां यह सलाह दी जाएगी कि कोई व्यक्ति किसी विशेष वर्ग का उत्तराधिकारी नहीं है या किसी विशेष विधि को ओवरराइड नहीं करता है। एक @final एनोटेशन या कुछ इसी तरह की तरह।

खैर, मैं इसमें क्या जोड़ूं कि "फाइनल" के लिए मतदान करने वाले अन्य सभी लोगों ने कहा है... इसके लिए मेरा वोट है।

माना। निश्चित रूप से, आप विधियों के साथ readonly उपयोग कर सकते हैं यदि आप इसे प्रकार के फ़ंक्शन की संपत्ति की तरह मानते हैं, लेकिन यह कामकाज बहुत भ्रमित हो सकता है। इस समस्या का मूल समाधान होना अच्छा होगा।

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

final जाने का रास्ता होना चाहिए

गिरोह - चूंकि यह टिकट (ए) बंद है, और (बी) में "अंतिम विधि" चर्चाओं के लिए एक भ्रामक शीर्षक है, इसलिए मैंने पूरी तरह से अंतिम तरीकों पर केंद्रित एक नया टिकट बनाने का फैसला किया। उम्मीद है कि इसे अनदेखा करना कठिन होगा और कुछ प्रगति को प्रोत्साहित भी कर सकता है। अरे हाँ देखें https://github.com/microsoft/TypeScript/issues/33446

@RyanCavanaugh

जटिलता बनाम मूल्य बार

क्या आप विस्तार से बता सकते हैं कि final बारे में इतना जटिल क्या है? मुझे ऐसा लगता है कि यह लागू करने के लिए सबसे आसान कीवर्ड में से एक होगा, विशेष रूप से यह देखते हुए कि abstract जैसे कीवर्ड पहले से ही लागू हैं, और उसमें से बहुत सारे तर्क/कोड का पुन: उपयोग किया जा सकता है।

@vinayluzrao

एक यादृच्छिक उदाहरण के रूप में, वर्तमान में हम कहते हैं कि आप किसी भी चीज़ से प्राप्त कर सकते हैं जिसमें एक निर्माण हस्ताक्षर है:

// OK
declare const SomeParent: new() => { a: string };
class A extends SomeParent { }

जाहिर है एक final वर्ग new -सक्षम है:

function make<T>(ctor: new() => T) {
  return ctor;
}
final class Done {
}
// No problem
const d = make(Done); // d: Done

लेकिन अब एक विरोधाभास है: हमारे पास एक चीज है जो new -सक्षम है, लेकिन extends खंड में रखना कानूनी नहीं है। तो अप्रत्यक्ष का एक स्तर final हरा देता है:

function subvertFinal(ctor: new() => any) {
  class Mwhahaah extends ctor {
    constructor() {
      super();
      console.log("I extended a final class! So much for 'types'!")
    }
  }
}
final class Done {
}
subvertFinal(Done);

यह पहले से ही लोगों को abstract और लोग लगातार तर्क दे रहे हैं कि abstract कक्षाओं में कुछ अंतर्निहित निर्माण हस्ताक्षर होना चाहिए जो टाइपचेकिंग उद्देश्यों के लिए मौजूद है लेकिन वास्तव में लागू करने योग्य या कुछ नहीं है।

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

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

@RyanCavanaugh जो वास्तव में इसे स्पष्ट करता है, धन्यवाद। हालांकि, मैं एक विचार फेंकना चाहूंगा: ऐसा लगता है कि आपके द्वारा दिए गए उदाहरण में समस्या new और extends बीच मजबूत युग्मन के कारण उत्पन्न हुई है, शायद यह बड़ी समस्या है , और स्वयं final । मुझे आश्चर्य है कि यह युग्मन निर्णय क्यों किया गया था, और इस बिंदु पर इसे पूर्ववत करना कितना कठिन होगा (बिल्कुल इसका मतलब यह नहीं है कि इसे पूर्ववत किया जाना चाहिए)।

मुझे यकीन नहीं है कि यह यहां चर्चा करने के लिए बहुत ही स्पर्शिक हो सकता है, हालांकि।

यह एक ऐसा मुद्दा है जिसमें मैं भाग गया। ऐसा सरल कोड नमूना संकलित नहीं किया जा सकता है।
final कीवर्ड इसे पूरी तरह से हल करेगा:

abstract class Parent {
    public abstract method(): this;
}

class Child extends Parent {
    public method(): this {
        return new Child();
    }
}

टाइप 'चाइल्ड' 'यह' टाइप करने के लिए असाइन करने योग्य नहीं है।
'चाइल्ड' टाइप 'इस' की बाधा के लिए असाइन करने योग्य है, लेकिन 'इस' को 'चाइल्ड' के एक अलग उपप्रकार के साथ इंस्टेंट किया जा सकता है।

खेल का मैदान

कृपया इसे फिर से खोला जा सकता है? यह स्पष्ट है कि इस सुविधा की आवश्यकता है

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

आप टाइपस्क्रिप्ट टीम के निर्णयों से असहमत हो सकते हैं, जो ठीक है, लेकिन हम उन निर्णयों को फिर से-फिर से-फिर-फिर से-फिर से तय करने वाली मंडलियों में घूमने में पूरा दिन नहीं बिता सकते हैं जिनसे लोग असहमत हैं। इस रेपो में वस्तुतः एक हजार अन्य सुझाव हैं जो इसे फिर से लाए जाने से पहले प्रारंभिक विचार के योग्य हैं।

@nicky1038 की टिप्पणी जैसी रचनात्मक चर्चा का यहाँ बहुत स्वागत है; मेरा अनुरोध है कि लोग समाचार/पुनर्विचार के अनुरोध के लिए इस धागे को लगातार पिंग न करें ताकि हमें इसे लॉक न करना पड़े।

मैं यहां विधियों के लिए फाइनल जोड़ने का समर्थन करने के लिए हूं। मेरे पास _init_ नामक फ़ंक्शन वाला बेस क्लास है कि मैं नहीं चाहता कि उप-वर्ग ओवरराइड करने में सक्षम हों। अंतिम सही समाधान होगा।

मैं विधियों के लिए final कीवर्ड जोड़ने का भी समर्थन करता हूं।
आजकल यह ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में एक मानक है।

final जोड़ना मुझे समझ में आता है। विशेष रूप से दूसरों के उपयोग के लिए पुस्तकालयों/ढांचे का निर्माण करते समय, जहां आप किसी फ़ंक्शन को ओवरराइड करने का जोखिम भी नहीं देना चाहते हैं।

अगर मैं final जोड़ने में गलती नहीं कर रहा हूं तो जेनेरिक के साथ काम करते समय 'myObj' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'MyClass' त्रुटियों के साथ परेशानी से बचने में मदद मिल सकती है क्योंकि मैं MyClass final बना सकता हूं और इसलिए वहां गारंटी देता हूं कोई अन्य उपप्रकार नहीं हैं।
100% निश्चित नहीं है, लेकिन मुझे लगता है कि आप जावा में इस मुद्दे को कैसे हल कर सकते हैं।

हमारे पास एक ही सामान है, हम कोणीय में आधार घटक बना रहे हैं कि कई अन्य पैकेजों को आधार के रूप में विस्तारित करने की आवश्यकता हो सकती है।
इसमें हमारे पास ngOnChanges या यहां तक ​​​​कि ngOnInit ऑफ एंगुलर जैसी चीजें हैं जिन्हें केवल बेस क्लास को लागू करना चाहिए और उपवर्गों को इन्हें ओवरराइड नहीं करना चाहिए, लेकिन वास्तव में ngOnInitReal (या जिसे हम इसे कहते हैं) को लागू करते हैं, इसलिए जब इसे कहा जाता है तो हम पूरी तरह से नियंत्रण में होते हैं। किसके साथ।
क्योंकि हम इसे नियंत्रित नहीं कर सकते, हम इसे केवल दस्तावेज़ीकरण के माध्यम से कर सकते हैं। यदि एक घटक निर्माता इसे नहीं पढ़ता है तो उसका घटक टूट सकता है, या उसे एक ही काम करने के लिए हमारे आधार से बहुत सारे कोड कॉपी करने की आवश्यकता होती है।

तो अंतिम तरीकों के बिना हम वास्तव में एक रॉक ठोस एपीआई अनुबंध नहीं कर सकते हैं।

क्या किसी ने उल्लेख किया

class Fancy {
    readonly secureFoo = (message: string) => {
        console.log(message);
    }
}

क्या किसी ने उल्लेख किया

class Fancy {
    readonly secureFoo = (message: string) => {
        console.log(message);
    }
}

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