वास्तव में एक अच्छा प्रस्ताव।

हालांकि निम्नलिखित उदाहरणों के बारे में क्या है, जो मेरे लिए मान्य ओवरराइड हैं:

class Snake extends Animal {
    override move(meters:number, height=-1):void {
    }
}

class A {...}
class Animal {
    setA(a: A): void {...}
    getA(): A {...}
}

class B extends A {...}
class Snake extends Animal {
    override setA(a: B): void {...}
    override getA(): B {...}
}

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

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

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

class C extends A {...}
var animal : Animal = new Snake();
animal.setA(new C());
// This will have undefined run-time behavior, as C will be interpreted as type B in Snake.setA

तो उदाहरण (2.) वास्तव में एक महान डेमो है कि कैसे एक ओवरराइड कीवर्ड संकलन समय पर सूक्ष्म किनारे के मामलों को पकड़ सकता है जो अन्यथा छूट जाएगा! :)

और मैं फिर से जोर दूंगा कि दोनों उदाहरण विशिष्ट नियंत्रित/उन्नत जावास्क्रिप्ट परिदृश्यों में मान्य हो सकते हैं जिनकी आवश्यकता हो सकती है ... इस मामले में उपयोगकर्ता ओवरराइड कीवर्ड को छोड़ना चुन सकते हैं।

यह उपयोगी होगा। हम वर्तमान में सुपर विधि के लिए एक डमी संदर्भ शामिल करके इसके आसपास काम करते हैं:

class Snake extends Animal {
    move(meters:number, height?:number):void {
         super.move; // override fix
    }
}

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

मुझे यह भी नहीं लगता कि व्युत्पन्न वर्ग विधि के हस्ताक्षर में डिफ़ॉल्ट और वैकल्पिक पैरामीटर संकलन त्रुटि को ट्रिगर करना चाहिए। यह सही हो सकता है लेकिन जावास्क्रिप्ट के अंतर्निहित लचीलेपन के खिलाफ जाता है।

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

class Snake extends Animal {
    move(meters:number, height:number):void {}
}

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

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

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

@rwyborn मुझे खुशी है कि आपने सी ++ कार्यान्वयन का उल्लेख किया है क्योंकि ठीक इसी तरह मैंने कल्पना की थी कि मुझे यहां आने से पहले काम करना चाहिए - वैकल्पिक रूप से। हालाँकि, एक संकलक ध्वज जिसने ओवरराइड कीवर्ड के उपयोग को मजबूर किया, वह मेरी पुस्तक में अच्छी तरह से नीचे जाएगा।

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

class Base {
    protected commitState() : void {

    }
}


class Implementation extends Base {
    override protected comitState() : void {   /// error - 'comitState' doesn't exist on base type

    }
}

वर्तमान में (1.4 के अनुसार) उपरोक्त Implementation वर्ग सिर्फ एक नई विधि की घोषणा करेगा और डेवलपर तब तक समझदार नहीं होगा जब तक कि वे नोटिस न करें कि उनका कोड काम नहीं कर रहा है।

सुझाव समीक्षा में चर्चा की।

हम निश्चित रूप से यहां उपयोग के मामलों को समझते हैं। समस्या यह है कि इसे इस स्तर पर भाषा में जोड़ने से जितना भ्रम दूर होता है, उससे कहीं अधिक भ्रम होता है। 5 विधियों वाला एक वर्ग, जिनमें से 3 को override के रूप में चिह्नित किया गया है, इसका अर्थ यह नहीं होगा कि अन्य 2 _aren't_ ओवरराइड नहीं करते हैं। अपने अस्तित्व को सही ठहराने के लिए, संशोधक को वास्तव में दुनिया को उससे कहीं अधिक सफाई से विभाजित करने की आवश्यकता होगी।

कृपया रोना क्षमा करें, लेकिन ईमानदारी से, जबकि आपका तर्क public कीवर्ड पर एक ऐसी भाषा में लागू होता है जहां सब कुछ डिफ़ॉल्ट रूप से सार्वजनिक है, वास्तव में काफी दुनिया विभाजित है, जिसमें abstract जैसी चीजें हैं और एक वैकल्पिक override कीवर्ड केवल डेवलपर्स को सुरक्षित महसूस करने, कम गलतियाँ करने और कम समय बर्बाद करने में मदद करेगा।

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

मैं @hdachev के साथ 100% सहमत हूं, @RyanCavanaugh द्वारा संदर्भित छोटी असंगतता को विधि ओवरराइड में संकलन समय जांच लाने में कीवर्ड के लाभों से आसानी से तौला जाता है। मैं फिर से बताऊंगा कि सी ++ वैकल्पिक ओवरराइड कीवर्ड का सफलतापूर्वक उसी तरह उपयोग करता है जैसे टाइपस्क्रिप्ट के लिए सुझाया गया है।

मैं इस बात पर जोर नहीं दे सकता कि जटिल ओओ पेड़ों के साथ बड़े पैमाने पर कोड बेस में ओवरराइड चेकिंग में कितना अंतर होता है।

अंत में मैं यह जोड़ूंगा कि यदि किसी वैकल्पिक कीवर्ड की असंगति वास्तव में एक चिंता का विषय है, तो C# दृष्टिकोण का उपयोग किया जा सकता है, जो कि "नया" या "ओवरराइड" कीवर्ड का अनिवार्य उपयोग है:

class Dervied extends Base {

    new FuncA(newParam) {} // "new" says that I am implementing a new version of FuncA() with a different signature to the base class version

    override FuncB() {} // "override" says that I am implementing exactly the same signature as the base class version

    FuncC() {} // If FuncC exists in the base class then this is a compile error. I must either use the override keyword (I am matching the signature) or the new keyword (I am changing the signature)
}

यह public के समान नहीं है क्योंकि बिना एक्सेस संशोधक वाली संपत्ति को सार्वजनिक माना जाता है; override के बिना एक विधि _not_ गैर-ओवरराइड होने के लिए जानी जाती है।

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

/* Put this in a helper library somewhere */
function override(container, key, other1) {
    var baseType = Object.getPrototypeOf(container);
    if(typeof baseType[key] !== 'function') {
        throw new Error('Method ' + key + ' of ' + container.constructor.name + ' does not override any base class method');
    }
}

/* User code */
class Base {
    public baseMethod() {
        console.log('Base says hello');
    }
}

class Derived extends Base {
    // Works
    <strong i="9">@override</strong>
    public baseMethod() {
        console.log('Derived says hello');
    }

    // Causes exception
    <strong i="10">@override</strong>
    public notAnOverride() {
        console.log('hello world');
    }
}

इस कोड को चलाने से एक त्रुटि उत्पन्न होती है:

त्रुटि: विधि नहीं व्युत्पन्न का ओवरराइड किसी भी आधार वर्ग विधि को ओवरराइड नहीं करता है

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

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

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

क्या आपकी आपत्तियां विशुद्ध रूप से लागत/लाभ पर आधारित हैं? अगर मुझे वास्तव में आगे बढ़ना था और इसे पीआर में लागू करना था तो क्या इसे स्वीकार किया जाएगा?

यह केवल लागत/लाभ का मुद्दा नहीं है। जैसा कि रयान ने समझाया, मुद्दा यह है कि एक विधि को ओवरराइड के रूप में चिह्नित करने का अर्थ यह नहीं है कि कोई अन्य विधि _is't_ ओवरराइड नहीं है। एकमात्र तरीका यह समझ में आता है कि यदि सभी ओवरराइड को override कीवर्ड के साथ चिह्नित करने की आवश्यकता है (जो कि यदि हम अनिवार्य हैं, तो यह एक ब्रेकिंग परिवर्तन होगा)।

@DanielRosenwasser जैसा कि ऊपर बताया गया है, C++ में ओवरराइड कीवर्ड वैकल्पिक है (बिल्कुल टाइपस्क्रिप्ट के लिए प्रस्तावित) फिर भी हर कोई इसका उपयोग करता है कोई समस्या नहीं है और यह बड़े कोड बेस पर बेहद उपयोगी है। इसके अलावा टाइपस्क्रिप्ट वास्तव में जावास्क्रिप्ट फ़ंक्शन ओवरलोडिंग के कारण वैकल्पिक होने के लिए बहुत अधिक समझ में आता है।

class Base {
    method(param: number): void { }
}

class DerivedA extends Base {
    // I want to *exactly* implement method with the same signature
    override method(param: number): void {}
}

class DerivedB extends Base {
    // I want to implement method, but support an extended signature
    method(param: number, extraParam: any): void {}
}

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

आप जानते हैं, मुझे लगता है कि आप लोगों को "ओवरराइड" की शाब्दिक व्याख्या पर ठीक किया गया है। वास्तव में यह जो चिह्नित कर रहा है वह "बिल्कुल_मैच_सिग्नेचर_ऑफ_सुपरक्लास_मेथोड" है, लेकिन यह काफी पठनीय नहीं है :)

class DerivedA extends Base {
    exactly_match_signature_of_superclass_method method(param: number): void {}
}

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

+1, टूलिंग भी बहुत बेहतर हो जाएगी। मेरा उपयोग मामला प्रतिक्रिया का उपयोग कर रहा है। हर बार जब मैं ComponentLifecycle विधियों का उपयोग कर रहा हूं तो मुझे निश्चितता की जांच करनी होगी:

``` सी#
इंटरफ़ेस घटकजीवनचक्र

{
कंपोनेंटविलमाउंट? (): शून्य;
कंपोनेंटडिडमाउंट? (): शून्य;
कंपोनेंटविल रिसीवप्रॉप्स? (नेक्स्टप्रॉप्स: पी, नेक्स्ट कॉन्टेक्स्ट: कोई भी): शून्य;
shouldComponentUpdate? (अगलाप्रॉप्स: पी, नेक्स्टस्टेट: एस, नेक्स्ट कॉन्टेक्स्ट: कोई भी): बूलियन;
कंपोनेंटविलअपडेट? (नेक्स्टप्रॉप्स: पी, नेक्स्टस्टेट: एस, नेक्स्ट कॉन्टेक्स्ट: कोई भी): शून्य;
कंपोनेंटडिडअपडेट? (पिछला प्रॉप्स: पी, प्रीवस्टेट: एस, प्रीव कॉन्टेक्स्ट: कोई भी): शून्य;
कंपोनेंटविलअनमाउंट? (): शून्य;
}

With override, or other equivalent solution,you'll get a nice auto-completion. 

One problem however is that I will need to override interface methods...

``` C#
export default class MyControlextends React.Component<{},[}> {
    override /*I want intellisense here*/ componentWillUpdate(nextProps, nextState, nextContext): void {

    }
}

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

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

सी ++ ओवरराइड के लिए माइक्रोसॉफ्ट के दस्तावेज़ीकरण चीजों को अच्छी तरह से बताता है, https://msdn.microsoft.com/en-us/library/jj678987.aspx

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

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

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

कई परियोजनाओं में काम करते समय बेस लाइब्रेरी में इंटरफ़ेस परिवर्तन टाइपस्क्रिप्ट जैसे एजेंडा वाली भाषा में होने से कठिन होता है।

हमारे पास बहुत अच्छी चीजें हैं, लेकिन फिर इस तरह की विषमताएं हैं और कोई वर्ग-स्तरीय कॉन्स गुण नहीं हैं।

@RyanCavanaugh सच है, लेकिन भाषा सेवा को ओवरराइड लिखने के बाद ट्रिगर किया जा सकता है, जैसा कि कई भाषाएं करती हैं, कीवर्ड के बिना यह पता लगाना बहुत कठिन है कि सही समय कब है।

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

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

जब आप ओवरराइड नहीं लिखते हैं तो क्या केवल एक चेतावनी जोड़कर असंगति को हल नहीं किया जा सकता है? मुझे लगता है कि टाइपस्क्रिप्ट समय के अंत के लिए खराब निर्णयों को संरक्षित करने के बजाय छोटे उचित ब्रेकिंग परिवर्तनों को जोड़कर सही काम कर रहा है।

इसके अलावा सार पहले से ही है, वे एक शानदार जोड़ी बनाएंगे :)

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

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

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

लेकिन, अगर ऐसी कोई विशेषता थी, तो हम इन वर्ग विधियों को आसानी से पा सकते हैं।

जैसा कि @RyanCavanaugh ने उल्लेख किया है, यदि यह कीवर्ड सिर्फ एक वैकल्पिक कीवर्ड है, तो यह सुविधा भ्रम पैदा करती है। तो, इस सुविधा को सक्षम करने के लिए tsc में कुछ झंडा कैसे बनाया जाए?

कृपया इस सुविधा पर फिर से विचार करें....

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

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

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

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

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

सभी +1ers के लिए -- क्या आप इस बारे में बात कर सकते हैं कि ऊपर दिखाए गए डेकोरेटर समाधान के बारे में क्या पर्याप्त नहीं है?

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

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

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

@RyanCavanaugh कुछ मुद्दे जो मैं देखता हूं:

• आईडीई के लिए कोड पूरा करने के लिए डेकोरेटर सिंटैक्स कठिन होगा (हाँ, मुझे लगता है कि यह किया जा सकता है लेकिन उन्हें पूर्व ज्ञान की आवश्यकता होगी)
• व्युत्पन्न वर्ग एक विधि की दृश्यता को बदल सकता है - जिसे सख्त शर्तों में अनुमति नहीं दी जानी चाहिए
• डेकोरेटर के लिए तर्क सूची और प्रकार, और संगत रिटर्न प्रकार की जांच करना मुश्किल है

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

और मुझे लगता है कि भले ही ओवरराइड प्रथम श्रेणी के कीवर्ड के रूप में मौजूद हो, हम हस्ताक्षर समानता के बारे में कुछ नए नियम लागू नहीं करेंगे।

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

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

कंपाइलर पहले से ही अवैध ओवरराइड की चेतावनी देगा। के साथ मुद्दा
ओवरराइड घोषित करते समय वर्तमान कार्यान्वयन इरादे की कमी है
तरीका।

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

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

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

बुधवार, 23 मार्च 2016 को 21:31 बजे, रोवन वायबोर्न नोटिफिकेशन @github.com ने लिखा:

और मुझे लगता है कि भले ही ओवरराइड प्रथम श्रेणी के कीवर्ड के रूप में मौजूद हो, हम
हस्ताक्षर समानता के बारे में कुछ नया नियम लागू नहीं करेगा।

@RyanCavanaugh https://github.com/RyanCavanaugh तो मुझे लगता है कि आप शायद
कीवर्ड के आशय के बारे में किसी भिन्न पृष्ठ पर हों। का पूरा बिंदु
यह उन मामलों के लिए है जहां आप हस्ताक्षर समानता को लागू करना चाहते हैं। इस
डिज़ाइन पैटर्न के लिए है जहाँ आपके पास एक गहरा जटिल पदानुक्रम है
एक बेस क्लास पर जो इंटरफ़ेस विधियों के अनुबंध को परिभाषित करता है, और सभी
पदानुक्रम में कक्षाएं _exactly_ उन हस्ताक्षरों से मेल खानी चाहिए। जोड़ कर
सभी व्युत्पन्न वर्गों में इन विधियों पर ओवरराइड कीवर्ड, आप हैं
किसी भी मामले के लिए सतर्क जहां हस्ताक्षर निर्धारित अनुबंध से अलग हो जाते हैं
बेस क्लास में।

जैसा कि मैं कहता रहता हूं कि यह कुछ गूढ़ उपयोग का मामला नहीं है। ए पर काम करते समय
बड़े कोड आधार (सैकड़ों या हजारों वर्गों के साथ) यह एक _every . है
दिन_ घटना, यानी किसी को आधार के हस्ताक्षर बदलने की जरूरत है
वर्ग (अनुबंध को संशोधित करें), और आप चाहते हैं कि संकलक आपको किसी के बारे में सचेत करे
पूरे पदानुक्रम में ऐसे मामले जो अब मेल नहीं खाते।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -200551774

@kungfusheep fwiw संकलक केवल अवैध ओवरराइड के एक निश्चित वर्ग को पकड़ता है, यही वह जगह है जहां घोषित पैरा के बीच सीधा संघर्ष होता है। यह _not_ पैरा को जोड़ने या हटाने को पकड़ता है, न ही यह रिटर्न प्रकार के परिवर्तनों को पकड़ता है। ये अतिरिक्त चेक वे हैं जो कोई भी ओवरराइड कीवर्ड स्विच ऑन करेगा।

यदि आप ओवरराइडिंग फ़ंक्शन के लिए पैरामीटर _add_ करते हैं तो कंपाइलर आपको सही चेतावनी देता है।

हालांकि, एक पैरामीटर को हटाना _toallyValid_ है:

class BaseEventHandler {
  handleEvent(e: EventArgs, timestamp: number) { }
}

class DerivedEventHandler extends BaseEventHandler {
  handleEvent(e: EventArgs) {
    // I don't need timestamp, it's OK
  }
}

वापसी प्रकार बदलना भी _toallyValid_ है:

class Base {
  specialClone(): Base { ... }
}
class Derived extends Base {
  specialClone(): Derived { ... }
}

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

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

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

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

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

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

हाँ सहमत। अगर मुझे चुनना पड़े, तो लापता-ओवरराइड/अवैध ओवरराइड स्थिति हल करने के लिए अधिक महत्वपूर्ण समस्या है।

मुझे पार्टी में थोड़ी देर हो गई है ... मुझे लगता है कि टाइपस्क्रिप्ट का पूरा बिंदु संकलन-समय पर नियमों को लागू करना है, न कि रनटाइम पर, अन्यथा हम सभी सादे जावास्क्रिप्ट का उपयोग करेंगे। साथ ही, इतनी सारी भाषाओं में मानक काम करने के लिए हैक्स/क्लज का उपयोग करना थोड़ा अजीब है।
क्या टाइपप्रति में override कीवर्ड होना चाहिए? मैं निश्चित रूप से ऐसा मानता हूं। क्या यह अनिवार्य होना चाहिए? संगतता कारणों से मैं कहूंगा कि इसका व्यवहार एक कंपाइलर तर्क के साथ निर्दिष्ट किया जा सकता है। क्या इसे सटीक हस्ताक्षर लागू करना चाहिए? मुझे लगता है कि यह एक अलग चर्चा होनी चाहिए, लेकिन मुझे अभी तक वर्तमान व्यवहार से कोई समस्या नहीं है।

इसे बंद करने का मूल कारण यह प्रतीत होता है कि हम ब्रेकिंग परिवर्तन पेश नहीं कर सकते हैं कि सभी ओवरराइड विधियों को override विनिर्देशक की आवश्यकता है, जो इसे भ्रमित कर देगा क्योंकि override के साथ चिह्नित नहीं की गई विधियों में भी हो सकता है तथ्य ओवरराइड हो।

इसे लागू क्यों न करें, या तो एक कंपाइलर विकल्प के साथ, और/या यदि कक्षा में override चिह्नित _at कम से कम एक_ विधि है, तो ओवरराइड होने वाली सभी विधियों को इस तरह चिह्नित किया जाना चाहिए, अन्यथा यह एक त्रुटि है?

क्या यह हवा में रहने के दौरान इसे फिर से खोलने लायक है?

शुक्र, 8 अप्रैल 2016 को 14:38 बजे, पीटर पालोटास नोटिफिकेशन @github.com ने लिखा:

इसे बंद करने का मूल कारण यह प्रतीत होता है कि हम परिचय नहीं दे सकते
ब्रेकिंग परिवर्तन कि सभी ओवरराइड विधियों को ओवरराइड की आवश्यकता होती है
विनिर्देशक, जो इसे भ्रमित कर देगा क्योंकि विधियों के साथ चिह्नित नहीं है
'ओवरराइड' वास्तव में ओवरराइड भी हो सकता है।

इसे लागू क्यों न करें, या तो एक कंपाइलर विकल्प के साथ, और/या यदि वहाँ है तो
कम से कम 'एक' विधि को कक्षा में ओवरराइड के रूप में चिह्नित किया गया है, फिर सभी विधियाँ जो हैं
ओवरराइड को इस तरह चिह्नित किया जाना चाहिए, अन्यथा यह एक त्रुटि है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -207434898

मैं कहता हूँ कृपया फिर से खोलो! मुझे एक कंपाइलर विकल्प से खुशी होगी।

हाँ - कृपया फिर से खोलें

इसे फिर से खोलें!

क्या ES7 को इस ओवरराइडिंग/ओवरलोडिंग कई विधियों की आवश्यकता नहीं है जो समान हैं
नाम?
8 अप्रैल 2016 को सुबह 10:56 बजे, "अराम तैयब" नोटिफिकेशन @github.com ने लिखा:

हाँ, कृपया इसे फिर से खोलें!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -2074666464

+1 - मेरे लिए यह टाइप सुरक्षा में सबसे बड़ा अंतर है जो मेरे पास दिन-प्रतिदिन टाइपस्क्रिप्ट विकास में है।

हर बार जब मैं "घटकडिडमाउंट" जैसी प्रतिक्रिया जीवनचक्र विधि लागू करता हूं, तो मैं प्रासंगिक प्रतिक्रिया प्रलेखन पृष्ठ की खोज करता हूं और यह सुनिश्चित करने के लिए विधि का नाम कॉपी/पेस्ट करता हूं कि मेरे पास टाइपो नहीं है। मैं ऐसा इसलिए करता हूं क्योंकि इसमें 20 सेकंड लगते हैं जबकि एक टाइपो से बग अप्रत्यक्ष और सूक्ष्म होते हैं, और उन्हें ट्रैक करने में अधिक समय लग सकता है।

5 विधियों वाली कक्षा, जिनमें से 3 को ओवरराइड के रूप में चिह्नित किया गया है, का अर्थ यह नहीं होगा कि अन्य 2 ओवरराइड नहीं हैं। अपने अस्तित्व को सही ठहराने के लिए, संशोधक को वास्तव में दुनिया को उससे कहीं अधिक सफाई से विभाजित करने की आवश्यकता होगी।

यदि यह प्रमुख चिंता का विषय है, तो कीवर्ड check_override पर कॉल करके यह स्पष्ट करें कि आप चेकिंग को ओवरराइड करने के लिए ऑप्ट इन कर रहे हैं, और इसका मतलब यह है कि अन्य विधियां _not overridden_ ​​के बजाय _not check_ हैं।

implements. का उपयोग करने के बारे में क्या? कुछ इस तरह होना:

class MyComponent extends React.Component<MyComponentProps, void>{
    implements.componentWillMount(){
        //do my stuff
    }
}

इस सिंटैक्स के कुछ फायदे हैं:

• यह पहले से मौजूद कीवर्ड का उपयोग करता है।
• implements. लिखने के बाद IDE के पास स्वतः पूर्णता पॉपअप दिखाने का एक उत्कृष्ट अवसर है।
• कीवर्ड स्पष्ट करता है कि बेस क्लास के अमूर्त तरीकों पर जांच को मजबूर करने के लिए इस्तेमाल किया जा सकता है लेकिन इंटरफेस भी लागू किया जा सकता है।
• सिंटैक्स इस तरह के क्षेत्रों के लिए भी प्रयोग करने योग्य होने के लिए पर्याप्त अस्पष्ट है:

class MyComponent<MyComponentProps, MyComponentState> {
    implements.state = {/*auto-completion for MyComponentState here*/};

    implements.componentWillMount(){
        //do my stuff
    }
}

नोट: वैकल्पिक रूप से हम base. का उपयोग कर सकते हैं, यह सॉर्टर और अधिक सहज है, लेकिन शायद अधिक भ्रमित (परिभाषित या कॉलिंग?) उदाहरण:

class MyComponent<MyComponentProps, MyComponentState> {
    base.state = {/*auto-completion for MyComponentState here*/};

    base.componentWillMount(){ //DEFINING
        //do my stuff
        base.componentWillMount(); //CALLING
        //do other stuff
    }
}

मुझे नहीं लगता कि implements सभी उपयोग के मामलों को पर्याप्त रूप से कवर करता है
पहले उल्लेख किया गया है और यह थोड़ा अस्पष्ट है। यह और नहीं देता
एक आईडीई को जानकारी है कि override या तो नहीं कर सका, इसलिए ऐसा प्रतीत होता है
शब्दावली के साथ रहने के लिए समझ में आता है कई अन्य भाषाओं का उपयोग किया जाता है
एक ही चीज़ हासिल करो।
बुध, 13 अप्रैल 2016 को 19:06 बजे, ओल्मो नोटिफिकेशन @github.com ने लिखा:

उपकरणों का उपयोग करने के बारे में क्या।? कुछ इस तरह होना:

वर्ग MyComponent React.Component का विस्तार करता है{
इम्प्लीमेंट्स.componentWillMount () {
// मेरा सामान करो
}
}

इस सिंटैक्स के कुछ फायदे हैं:

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

वर्ग MyComponent{
इम्प्लीमेंट्स.स्टेट = {/_ MyComponentState के लिए ऑटो-पूर्णता यहाँ_/};

implements.componentWillMount(){
    //do my stuff
}

}

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -209571753

ओवरराइड के साथ समस्या यह है कि एक बार जब आप एक ही कीवर्ड का उपयोग करते हैं तो आपको वही अपेक्षाएं होती हैं:

• यह अनिवार्य होना चाहिए, कम से कम यदि विधि abstract है।
• फिर आप कुछ virtual कीवर्ड को उन तरीकों की व्याख्या करने से चूक जाते हैं जिन्हें ओवरराइड किया जाना है लेकिन डिफ़ॉल्ट व्यवहार है।

मुझे लगता है कि TS टीम भाषा में इतना OO सामान नहीं जोड़ना चाहती है, और मुझे लगता है कि यह एक अच्छा विचार है।

implements. का उपयोग करके आपके पास मुख्य लाभ प्राप्त करने के लिए हल्का सिंटैक्स होता है: नए कीवर्ड का आविष्कार किए बिना या अवधारणा गणना में वृद्धि के बिना स्वत: पूर्ण और संकलन-समय चेक किया गया नाम।

कक्षाओं और इंटरफेस के लिए और विधियों (प्रोटोटाइप में) या प्रत्यक्ष क्षेत्रों के लिए काम करने का भी लाभ है।

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

virtual कीवर्ड वास्तव में भाषा के संदर्भ में कोई मतलब नहीं रखता है और न ही इसका नाम इस तरह से रखा गया है जो उन लोगों के लिए सहज है जिन्होंने पहले सी ++ जैसी भाषाओं का उपयोग नहीं किया है। शायद इस प्रकार का गार्ड प्रदान करने का एक बेहतर समाधान, यदि आवश्यक हो, तो final कीवर्ड होगा।

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

विरासत में मिले फ़ील्ड बनाम नए को फिर से परिभाषित करने के बारे में क्या? प्रतिक्रिया state एक अच्छा उदाहरण है।

या वैकल्पिक इंटरफ़ेस विधियों को लागू करना?

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

गुरु, 14 अप्रैल 2016 को 11:58 बजे, ओल्मो नोटिफिकेशन @github.com ने लिखा:

विरासत में मिले फ़ील्ड बनाम नए को फिर से परिभाषित करने के बारे में क्या? प्रतिक्रिया राज्य
एक अच्छा उदाहरण है।

या वैकल्पिक इंटरफ़ेस विधियों को लागू करना?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -209879217

वैकल्पिक इंटरफ़ेस विधियाँ ओवरराइड नहीं होती हैं, इसलिए हम यहाँ जिस बारे में बात कर रहे हैं उसके दायरे से बाहर हैं।

जहां तक ​​​​मुझे पता है, वैकल्पिक इंटरफ़ेस विधियां टाइपस्क्रिप्ट के लिए काफी अनूठी अवधारणा हैं, और मुझे लगता है कि "ओवरराइड" का टाइपस्क्रिप्ट कार्यान्वयन उन पर लागू होना चाहिए।

घटकडिडमाउंट जैसे रिएक्ट जीवनचक्र विधियों के मामले में, ये वैकल्पिक इंटरफ़ेस विधियाँ हैं जिनका सुपरक्लास में कोई कार्यान्वयन नहीं है।

घटकडिडमाउंट जैसे रिएक्ट जीवनचक्र विधियों के मामले में, ये वैकल्पिक इंटरफ़ेस विधियाँ हैं जिनका सुपरक्लास में कोई कार्यान्वयन नहीं है।

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

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

क्या हम सभी सहमत हो सकते हैं कि हमें override की आवश्यकता है और टाइपस्क्रिप्ट टीम से इसे जोड़ने के लिए कहें या अनुरोध को छोड़ दें और समस्या को बंद कर दें?

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

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

@armandn मुझे नहीं लगता कि हमारे बंद होने की कमी या हमारे सुझाव की अच्छाई वह है जो अनुरोध को खारिज कर रही है, लेकिन C# और TS शब्दार्थ के बीच अंतर:

सी # आधार विधि ओवरराइड:

• override कीवर्ड की आवश्यकता है
• VTable पर एक नया रिकॉर्ड बनाता है
• आधार पद्धति में अनिवार्य सार/आभासी के लिए जाँच करता है
• समान हस्ताक्षर के लिए जाँच
• आईडीई: ओवरराइड लिखने के बाद स्वत: पूर्ण ट्रिगर करता है

सी # इंटरफ़ेस कार्यान्वयन:

• कोई कीवर्ड आवश्यक नहीं है, लेकिन इंटरफ़ेस नाम का उपयोग करके स्पष्ट इंटरफ़ेस कार्यान्वयन संभव है।
• VTable में एक नया इंटरफ़ेस रिकॉर्ड बनाएँ।
• समान हस्ताक्षर के लिए जाँच
• आईडीई: इंटरफ़ेस लागू करने के लिए क्विकफ़िक्स/इंटरफ़ेस को स्पष्ट रूप से कार्यान्वित करें।

तो यदि आप कक्षाओं या इंटरफेस के बारे में पूछते हैं तो सी # में व्यवहार काफी भिन्न होता है, लेकिन किसी भी मामले में आपको मुख्य तीन लाभ मिलते हैं:

1. समान हस्ताक्षर के लिए जाँच हो रही है
2. जाँच कर रहा है कि विधि को ओवरराइड किया जा सकता है/होना चाहिए (विधि नाम में गलत वर्तनी)
3. IDE फ़ंक्शन लिखने का समर्थन करता है

थोड़े अलग शब्दार्थ के साथ, हमारे पास पहले से ही 1) टीएस में, दुर्भाग्य से 2) और 3) गायब हैं। कारण override को अस्वीकार कर दिया गया था, मेरी राय में, एक समान वाक्यविन्यास एक समान व्यवहार मानता है, और यह वांछनीय नहीं है क्योंकि:

5 विधियों वाला एक वर्ग, जिनमें से 3 को ओवरराइड के रूप में चिह्नित किया गया है, इसका अर्थ यह नहीं होगा कि अन्य 2 ओवरराइड नहीं हैं।

ऐसा होता है कि हमारे पास पहले से ही 1) 2) और 3) _ऑब्जेक्ट लिटरल्स_ लिखते समय, लेकिन क्लास के सदस्यों को लिखते समय नहीं जो अन्य वर्गों का विस्तार करते हैं या इंटरफेस लागू करते हैं।

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

• 'विभाजित दुनिया' की समस्या से बचने के लिए _कीवर्ड_ पर्याप्त अस्पष्ट होना चाहिए। (यानी: check या super. , या MyInterface. )
• abstract/virtual के लिए कोई चेक नहीं है लेकिन बेस क्लास/कार्यान्वित इंटरफेस में सदस्य अस्तित्व की जांच करता है। (लाभ 2)
• समान-पर्याप्त हस्ताक्षर संगतता के लिए जाँच करता है जैसा कि TS अब तक कर रहा है। (लाभ 1)
• IDE: कीवर्ड के बाद स्वत: पूर्ण होने को ट्रिगर करता है। (लाभ 3)

इसके अतिरिक्त, मुझे लगता है कि समाधान की पूर्णता के लिए ये दोनों आवश्यक हैं*:

• इसे क्लासेस और इंटरफेसेस के लिए काम करना चाहिए, क्योंकि टीएस मुख्य रूप से इंटरफेस आधारित है और क्लास प्रोटोटाइप इनहेरिटेंस के लिए एक शॉर्टकट हैं। वैकल्पिक इंटरफ़ेस विधियों पर विचार करना आवश्यक है।
• इसे मेथड्स और फील्ड्स के लिए काम करना चाहिए, क्योंकि मेथड्स सिर्फ एक फील्ड में रहने वाले फंक्शन हैं।

रिएक्ट घटक कार्यान्वयन के वास्तविक उपयोग के मामले में ये दो बिंदु उपयोगी हैं:

``` सी#
वर्ग MyComponent{
इम्प्लीमेंट्स.स्टेट = {/ MyComponentState के लिए ऑटो-कम्प्लीशन यहाँ /};

implements.componentWillMount(){
    //do my stuff
}

}
```

@RyanCavanaugh से एनोटेशन-आधारित समाधान पर्याप्त नहीं है क्योंकि:

• यह इंटरफेस के साथ काम नहीं करेगा।
• यह खेतों के साथ काम नहीं करेगा।
• टूलींग के साथ मदद करने के लिए रोज़लिन जैसी बुनियादी ढांचे को मानते हुए, @override लिखने के बाद स्वत: पूर्ण सूची लिखने के बाद QuickFix जोड़ने का कोई तरीका नहीं है।

शब्दार्थ को देखते हुए, यह केवल सही वाक्य रचना चुनने के बारे में है। यहाँ कुछ विकल्प:

• override componentWillMount() : सहज लेकिन भ्रामक।
• check componentWillMount() : स्पष्ट लेकिन कीवर्ड-उपभोक्ता।
• super componentWillMount() :
• implements componentWillMount() :
• super.componentWillMount() :
• implements.componentWillMount() :
• this.componentWillMount() :
• ReactComponent.componentWillMount() :

राय?

@olmobrutall अच्छा सारांश। अंक की जोड़ी:

एक कीवर्ड विकल्प (सी# से लिया गया) नया होगा - एक नया स्लॉट इंगित करना:

class MyComp extends React.Component<IProps,IState> {
...
    new componentWillMount() { ... }
    componentWillMount() { ...} // would compile, maybe unless strict mode is enabled
    new componentwillmount() { ... } <-- error

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

class Component<P,S> {
    extendable componentWillMount() {...}
}

यही बात इंटरफेस पर भी लागू होगी।

धन्यवाद :)

सिर्फ this लिखने के बारे में क्या?

class MyComponent<MyComponentProps, MyComponentState> {
    this.state = {/*auto-completion for MyComponentState here*/};

    this.componentWillMount(){
        //do my stuff
    }
}

लगभग extendable , TS 1.6 में पहले से ही abstract है, और वर्चुअल जोड़ने से शायद फिर से विभाजित दुनिया की समस्या पैदा हो जाएगी?

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

this. काम करता है, मुझे लगता है कि आपके पास भी हो सकता है (एक लंबे रूप के रूप में):

   this.componentWillMount = () => { }

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

क्या चल र...

टाइपस्क्रिप्ट C# का जावास्क्रिप्ट संस्करण नहीं है और न ही कभी रहा है। तो इसका कारण यह नहीं है कि सुझाई गई कार्यक्षमता C# के शब्दार्थ से भिन्न है। रयान द्वारा बताए गए और फिर डेनियल आर द्वारा स्पष्ट किए गए बंद करने के कारण थे:

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

फिर भी आप अभी भी स्वतः पूर्ण के आसपास अपनी समस्याओं से जूझ रहे हैं। आपको बेहतर सुझाव प्रदान करने के लिए स्वतः पूर्ण को भाषा में किसी नए कीवर्ड की आवश्यकता नहीं है।

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

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

टाइपस्क्रिप्ट C# का जावास्क्रिप्ट संस्करण नहीं है और न ही कभी रहा है।

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

आपको बेहतर सुझाव प्रदान करने के लिए स्वतः पूर्ण को भाषा में किसी नए कीवर्ड की आवश्यकता नहीं है।

आप इसे तब ट्रिगर करने का सुझाव कैसे देते हैं? यदि आप एक वर्ग संदर्भ में एक यादृच्छिक नाम लिखते समय एक स्वत: पूर्ण कम्बोबॉक्स दिखाते हैं तो हम बहुत परेशान होंगे जब हम सिर्फ एक नया क्षेत्र या विधि घोषित करना चाहते हैं।

जब कोई फ़ंक्शन अवैध रूप से ओवरराइड किया जाता है या जब किसी विधि को ओवरराइड घोषित किया जाता है, लेकिन वास्तव में बेस क्लास में किसी फ़ंक्शन को ओवरराइड नहीं किया जाता है, तो यह थ्रेड मौजूद होने का कारण कंपाइलर त्रुटियां प्राप्त करना था।

मैंने पूरी तरह से इस उपयोग के मामले को लाभ 2 के तहत शामिल किया है।

इसे दुनिया की सभी समस्याओं को हल करने की आवश्यकता नहीं है, इसे केवल ओवरराइड कीवर्ड होना चाहिए, ओवरराइड के लिए।

तो आपका सुझाव है कि एक कदम पीछे जाने के बजाय एक बार में _एक कदम ठीक करें और समान/संबंधित समस्याओं को देखें। यह शायद आपके स्क्रम बोर्ड के लिए एक अच्छा विचार है लेकिन भाषाओं को डिजाइन करने के लिए नहीं।

कीवर्ड जोड़ने के बारे में उनके रूढ़िवादी होने का कारण यह है कि वे किसी भाषा से सुविधाओं को नहीं हटा सकते हैं।

सी # में कुछ डिज़ाइन गलतियाँ पूर्णता की कमी के कारण:

• असुरक्षित सरणी सह-प्रसरण / अंतर-प्रसरण।
• var केवल परिवर्तनीय प्रकारों के लिए काम कर रहा है, स्वचालित जेनेरिक पैरामीटर या रिटर्न प्रकारों के लिए नहीं। मेबल auto C++ की तरह एक बेहतर कीवर्ड होगा?

बस एक सेकंड के लिए रिएक्ट का उपयोग करने का प्रयास करें और आप तस्वीर के दूसरी तरफ देखेंगे।

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

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

यदि आपकी मुख्य चिंता स्वतः पूर्ण है, तो संपादकों के पास पर्याप्त जानकारी _now_ है जो आधार वर्गों और कार्यान्वित इंटरफेस से विधियों का सुझाव देने में सक्षम होने के लिए 'जैसा कि आप टाइप करते हैं'।

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

सामान्य स्थिति में हाँ, लेकिन हम किसी इंटरफ़ेस पद्धति को लागू करने के बारे में बात नहीं कर रहे हैं। हम एक वैकल्पिक इंटरफ़ेस विधि के बारे में बात कर रहे हैं _जहां मूल वर्ग इंटरफ़ेस लागू करता है_। इस मामले में आप कह सकते हैं कि 1) इंटरफ़ेस विधि को undefined के रूप में कार्यान्वित करने की अनुमति देता है, 2) मूल वर्ग में एक अपरिभाषित कार्यान्वयन होता है, और 3) बाल वर्ग एक विधि कार्यान्वयन के साथ अपरिभाषित कार्यान्वयन को ओवरराइड कर रहा है।

@olmobrutall मुझे लगता है कि भाषाओं को डिजाइन करने के बारे में आपकी टिप्पणी और यह कैसे एक स्क्रम बोर्ड नहीं है, थोड़ा आत्म-सेवारत है। मैंने एक साल से कम के स्पेस में TS के बारे में चार अपडेट देखे हैं।

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

मैं यह टिप्पणी टीएस डेवलपर्स/डिजाइनरों के किसी भी अपमान के साथ नहीं करता, क्योंकि टीएस पहले से ही उत्कृष्ट है और मुझे इसके बजाय मानक जेएस का उपयोग करने से डर लगता है।

हाँ TS C# नहीं है और यह C++ नहीं है। लेकिन कई भाषाओं ने यहां चर्चा किए गए उद्देश्यों को पूरा करने के लिए ओवरराइड कीवर्ड को चुना है, इसलिए पूरी तरह से विदेशी वाक्यविन्यास का सुझाव देना उल्टा लगता है।

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

हस्ताक्षर अंतर एक अलग बातचीत है। नया कीवर्ड अनावश्यक प्रतीत होता है क्योंकि JS एक ही नाम के कई तरीकों का समर्थन नहीं कर सकता है (जब तक कि TS हस्ताक्षर-व्युत्पन्न मैंगल्ड नाम a'la C++ नहीं बनाता, जिसकी अत्यधिक संभावना नहीं है)।

मैंने एक साल से कम के स्पेस में TS के बारे में चार अपडेट देखे हैं।

मेरा मतलब यह नहीं है कि आप तेज नहीं हो सकते और जल्दी से पुनरावृति नहीं कर सकते। मैं किसी भी व्यक्ति की तरह खुश हूं कि ES6 और TS तेजी से विकसित हो रहे हैं। मेरा मतलब यह है कि आपको भविष्य की भविष्यवाणी करने की कोशिश करनी होगी, भाषा को मृत अंत में डालने से बचने के लिए।

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

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

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

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

सामान्य स्थिति में हाँ, लेकिन हम किसी इंटरफ़ेस पद्धति को लागू करने के बारे में बात नहीं कर रहे हैं। हम एक वैकल्पिक इंटरफ़ेस विधि के बारे में बात कर रहे हैं जहाँ मूल वर्ग इंटरफ़ेस लागू करता है।

इससे कोई फर्क नहीं पड़ता कि इंटरफ़ेस कहाँ स्थापित किया गया था, तथ्य यह है कि वे एक ही चीज़ नहीं हैं और इसलिए एक कीवर्ड साझा नहीं करना चाहिए क्योंकि प्रोग्राम का _intent_ स्पष्ट नहीं है।

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

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

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

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

तथ्य यह है कि वे एक ही चीज नहीं हैं और इसलिए उन्हें एक कीवर्ड साझा नहीं करना चाहिए क्योंकि कार्यक्रम का इरादा स्पष्ट नहीं है।

नहीं हैं? BaseClass . की इन दो वैकल्पिक परिभाषाओं को देखें

class BaseClass {
     abstract myMethod(); 
}

interface ISomeInterface {
     myMethod?(); 
}

class BaseClass extends ISomeInterface {
}

और फिर आपके कोड में आप करते हैं:

``` सी#
वर्ग कंक्रीटक्लास {
myMethod को ओवरराइड करें () {
// कार्य करना
}
}

You think it should work in just one case and not in the other? The effect is going to be 100% identical in Javascript (creating a new method in ConcreteClass prototype), from the external interface and from the tooling perspective. 

Even more, maybe you want to capture `this` inside of the method, implementing it with a lambda (useful for React event handling). In this case you'll write something like this:

``` C#
class ConcreteClass {
    override myMethod = () => { 
         // Do stuff
    }
}

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

आइए इसे super. का उपयोग करके न देखें (अभी मेरा पसंदीदा सिंटैक्स है, लेकिन मैं विकल्पों के लिए खुला हूं)।

``` सी#
वर्ग कंक्रीटक्लास {
super.myMethod () {// प्रोटोटाइप में विधि
// कार्य करना
}

super.myMethod = () => {  //method in lambda
     // Do stuff
}

}
```

अब अवधारणा अवधारणात्मक रूप से सरल है: मेरा सुपर क्लास कहता है कि एक विधि या क्षेत्र है और कंक्रीट क्लास इसे प्रोटोटाइप में परिभाषित कर सकता है/इसे असाइन कर सकता है/इसे पढ़ सकता है/इसे कॉल कर सकता है।

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

सिर्फ प्रतिक्रिया नहीं है, कोणीय को देखो:

• प्रतिक्रिया : 58 इंटरफेस और 3 कक्षाएं।
• कोणीय : 108 इंटरफेस और 11 कक्षाएं।

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

क्या आपने इंटरफ़ेस कार्यान्वयन के बारे में कुछ करने का सुझाव देने के लिए एक और मुद्दा खोलने का प्रयास किया है?

मुझे इसे कैसे कॉल करना चाहिए? इंटरफ़ेस और फ़ील्ड के लिए override ?

हम एक आजमाई हुई और परखी हुई तकनीक का सुझाव दे रहे हैं जो मेरे विचार से हर दूसरी भाषा में सफल रही है।

आपके मन में जो भाषाएं हैं वे काफी अलग हैं। उनके पास एक स्थिर VTable में आधारित विरासत है।

टाइपस्क्रिप्ट में एक वर्ग सिर्फ एक इंटरफ़ेस + विधियों का स्वचालित प्रोटोटाइप विरासत है। और विधियां केवल एक फ़ंक्शन वाले फ़ील्ड हैं।

override सुविधा को TS के अनुकूल बनाने के लिए इन दो मूलभूत अंतरों पर विचार करना होगा।

कृपया @kungfushiep मेरी समस्या के समाधान के बारे में सोचने का प्रयास करें। यदि आप अलग-अलग कीवर्ड जोड़ना चाहते हैं और उन्हें दूसरे चरण में लागू करना चाहते हैं तो ठीक है, लेकिन एक सेकंड के लिए कल्पना करें कि यह कैसा होना चाहिए।

जो मैं पहले ही कह चुका हूं, उसे कहने का मैं कोई दूसरा तरीका नहीं सोच सकता। वे एक जैसे नहीं हैं। वे समान हैं, लेकिन समान नहीं हैं। कृपया इस टिप्पणी को TS devs RE में से किसी एक द्वारा देखें: केवल पढ़ने योग्य कीवर्ड - https://github.com/Microsoft/TypeScript/pull/6532#issuecomment -179563753 - जो कि मैं जो कह रहा हूं उसे मजबूत करता है।

मैं सामान्य विचार से सहमत हूं, लेकिन आइए व्यवहार में देखें:

class MyComponent extends React.Component<{ prop : number }, { value: string; }> {

    //assign a field defined in the base class without re-defining it (you want type-checking)
    assign state = { value : number}; 

    //optional method defined in an interface implemented by the base class    
    implement componentDidMount(){ 
    }

    //abstract method defined in the base class 
    override render(){  
    }
}

यह वीबी या कोबोल जैसा दिखता है, है ना?

ऐसा लगता है कि यह समझ में आता है, कम से कम।

इस उदाहरण पर विचार करें, क्या केवल ओवरराइड (या सिर्फ एक) कीवर्ड था।

interface IDo {
    do?() : void;
}
class Component implements IDo {
    protected commitState() : void {
        /// do something
    }
    override public do() : void {
        /// base implements 'do' in this case
    }
}

अब हमने जो लिखा है उसका उपयोग करके अपने स्वयं के घटक को लागू करने दें।

class MyComponent extends Component {
    override protected commitState(){
        /// do our own thing here
        super.commitState();
    }
    override do() : void {
        /// this is ambiguous. Am I implementing this from an interface or overriding a base method? I have no way of knowing. 
    }

}

जानने का एक तरीका super का प्रकार होगा:

  override do() : void {
        super.do(); // this compiles, if it was an interface then super wouldn't support `do`
    }

बिल्कुल सही! यानी डिजाइन गलत है। स्किमिंग कोड से जुड़ी कोई जांच नहीं होनी चाहिए, जब आप इसे पढ़ते हैं तो यह केवल समझ में आता है।

यह अस्पष्ट है। क्या मैं इसे इंटरफ़ेस से कार्यान्वित कर रहा हूं या मूल विधि को ओवरराइड कर रहा हूं? मेरे पास जानने का कोई तरीका नहीं है।

व्यवहार में क्या अंतर है? ऑब्जेक्ट में नामों का केवल एक स्थान है और आप do फ़ील्ड में केवल एक लैम्ब्डा रख सकते हैं। वैसे भी इंटरफ़ेस को स्पष्ट रूप से कार्यान्वित करने का कोई तरीका नहीं है। कार्यान्वयन होने जा रहा है:

MyComponent.prototype.do = function (){
    //your stuff
}

आप जो लिखते हैं उससे स्वतंत्र।

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

दो कीवर्ड होने से कौन सी त्रुटि या अनपेक्षित व्यवहार हल हो जाएगा?

चलो अब यार। आप स्पष्ट रूप से एक चतुर व्यक्ति हैं। मैंने अभी कहा है "अनजाने में बेस क्लास में कुछ कार्यक्षमता को ओवरराइड करना"; क्या हम इससे किसी भी अप्रत्याशित व्यवहार का अनुमान नहीं लगा सकते हैं जो संभावित रूप से अभी-अभी हुआ हो सकता है?

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

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

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

हमें 1, 2 या 3 कीवर्ड की आवश्यकता है या नहीं, इसके लिए तर्क इस धागे से संबंधित हैं और समाप्त नहीं हुए हैं (...लेकिन दोहराए जा रहे हैं)। तब शायद हम किसी अन्य सूत्र में वाक्य रचना पर चर्चा कर सकते हैं (क्योंकि शब्दार्थ वैसे भी समान होने जा रहे हैं: P)।

मेरे उदाहरण में:

class MyComponent extends React.Component<{ prop : number }, { value: string; }> {

    //assign a field defined in the base class without re-defining it (you want type-checking)
    assign state = { value : number}; 

    //optional method defined in an interface implemented by the base class    
    implement componentDidMount(){ 
    }

    //abstract method defined in the base class 
    override render(){  
    }
}

assign , implement और override बिल्कुल वही काम न करें: जांचें कि नाम मौजूद है (बेस क्लास में, कार्यान्वित इंटरफेस, आधार द्वारा कार्यान्वित इंटरफेस वर्ग, आदि ...)

यदि आधार वर्गों और कुछ कार्यान्वित इंटरफेस के बीच कोई नाम संघर्ष है तो आपको एक संकलन-समय त्रुटि मिलेगी चाहे 1, 2 या कोई कीवर्ड न हो।

वस्तु शाब्दिक के बारे में भी सोचें:

var mc = new MyComponent(); 
mc.state = null;
mc.componentDidMount =null;
mc.render = null;

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

असाइन न करें, लागू करें और ओवरराइड करें बिल्कुल वही काम करें: जांचें कि नाम मौजूद है (बेस क्लास में, कार्यान्वित इंटरफेस, बेस क्लास द्वारा कार्यान्वित इंटरफेस, आदि ...)।

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

#6118 के बंद होने के साथ मुझे लगता है कि चर्चा करने का कारण है कि क्या वहां की समस्याएं और यहां की समस्याओं को एक साथ संबोधित किया जा सकता है।

मुझे https://github.com/Microsoft/TypeScript/pull/6118 की जानकारी नहीं थी। यह विचार override जोड़ने के संभावित विकल्प की तरह दिखता है।

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

परिणामों का एक अच्छा विचार किए बिना, मुझे खुशी होगी यदि:

• सदस्य एक संकलन-समय त्रुटि उत्पन्न करेगा जिसके लिए बाल वर्ग पर स्पष्ट प्रकार की घोषणा की आवश्यकता होती है
• सदस्य सभी संभावित प्रकारों का प्रतिच्छेदन करेगा।

कक्षा के सदस्यों (Ctrl + Space) लिखते समय स्वत: पूर्णता को ट्रिगर करने का कोई तरीका होना अधिक महत्वपूर्ण आईएमओ होगा। जब कर्सर सीधे एक वर्ग के अंदर होता है, तो आप विरासत में मिले लोगों को फिर से परिभाषित करने के नए सदस्यों को परिभाषित कर सकते हैं, इसलिए स्वत: पूर्णता बहुत आक्रामक नहीं हो सकती है, लेकिन व्यवहार को मैन्युअल रूप से ट्रिगर करने के साथ ठीक होना चाहिए।

@RyanCavanaugh टिप्पणियों के बारे में:

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

किसी चर को any के रूप में लिखने का यह अर्थ नहीं है कि कोई अन्य चर भी any है या नहीं। लेकिन, इसे लागू करने के लिए एक कंपाइलर फ्लैट --no-implicit-any है जिसे हम स्पष्ट रूप से घोषित करते हैं। हमारे पास समान रूप से --no-implicit-override हो सकता है, जिसे मैं उपलब्ध होने पर चालू कर दूंगा।

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

सभी +1ers के लिए -- क्या आप इस बारे में बात कर सकते हैं कि ऊपर दिखाए गए डेकोरेटर समाधान के बारे में क्या पर्याप्त नहीं है?

क्या कोई तरीका है जिसमें एक डेकोरेटर एक ओवरराइड कीवर्ड से बेहतर समाधान है? इसके खराब होने के कई कारण हैं: 1) यह रनटाइम ओवरहेड को जोड़ता है चाहे वह कितना भी छोटा क्यों न हो; 2) यह एक संकलन समय जांच नहीं है; 3) मुझे इस कोड को अपने प्रत्येक पुस्तकालय में शामिल करना होगा; 4) इसके लिए उन कार्यों को पकड़ने का कोई तरीका नहीं है जिनमें ओवरराइड कीवर्ड गुम है।

आइए एक उदाहरण देते हैं। मेरे पास तीन वर्गों के साथ एक पुस्तकालय है ChildA , ChildB , Base । मैंने doSomething() से ChildA और ChildB में कुछ विधि जोड़ी है। कुछ रिफैक्टरिंग के बाद, मैंने कुछ अतिरिक्त तर्क जोड़े हैं, अनुकूलित किए हैं, और doSomething() को Base वर्ग में स्थानांतरित कर दिया है। इस बीच, मेरे पास एक और प्रोजेक्ट है जो मेरी लाइब्रेरी पर निर्भर करता है। वहां मेरे पास ChildC के साथ doSomething() है। कोई रास्ता नहीं है जब मैं यह पता लगाने के लिए अपनी निर्भरता को अपडेट करता हूं कि ChildC अब निहित रूप से ओवरराइड कर रहा है doSomething() , लेकिन एक अडॉप्टाइज्ड तरीके से जिसमें कुछ चेक भी गायब हैं। इसलिए एक @overrides डेकोरेटर कभी भी पर्याप्त नहीं होगा।

हमें एक override कीवर्ड और एक --no-implicit-override कंपाइलर फ्लैग की आवश्यकता है।

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

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

लेकिन शायद मुझे ऐसा नहीं करना चाहिए था। निम्नलिखित संभावनाएं मानती हैं कि मैंने एक निहित ओवरराइड किया है:

1. बेस क्लास ने पहले से ही इस विधि को परिभाषित किया है जैसे मैंने किया था, इसलिए मैंने कुछ भी नहीं के लिए एक फ़ंक्शन लिखा। इतनी समस्या नहीं है।
2. मैंने फ़ंक्शन को गलत तरीके से फिर से लिखा, ज्यादातर समय क्योंकि मैं कुछ गैर-स्पष्ट सामान करना भूल गया था जो पहले से ही बेस क्लास द्वारा नियंत्रित किया गया था। मुझे वास्तव में यहां क्या करने की ज़रूरत है, मेरे ओवरराइड में super पर कॉल करें, लेकिन किसी ने मुझे ऐसा करने का सुझाव नहीं दिया।

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

बेशक, जैसा कि सुझाव दिया गया है, इसे --no-implicit-override ध्वज के नीचे रखा जाना चाहिए क्योंकि यह एक ब्रेकिंग परिवर्तन होगा और अधिकांश लोगों को इस सब के बारे में ज्यादा परवाह नहीं है।

मुझे any और --no-implicit-any के साथ किए गए @eggers की तुलना पसंद है क्योंकि यह उसी तरह का एनोटेशन है और यह ठीक उसी तरह काम करेगा।

@olmobrutall मैं अमूर्त विधियों और इंटरफ़ेस विधियों को ओवरराइड करने के बारे में आपकी कुछ बातों को देख रहा था।

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

यहां समस्याएं हैं जैसा कि मैं उन्हें देखता हूं, सबसे महत्वपूर्ण से कम से कम रैंक किया गया है। क्या मैं कुछ भूल गया?

ओवरराइड करने में विफलता

जब आप नहीं होते हैं तो _थिंक_ करना आसान होता है जब आप बेस क्लास विधि को ओवरराइड कर रहे होते हैं:

class Base {
  hasFilename(f: string) { return true; }
}
class Derived extends Base {
  // oops
  hasFileName(f: string) { return false; }
}

शायद यही सबसे बड़ी समस्या है।

लागू करने में विफलता

यह बहुत निकट से संबंधित है, खासकर जब कार्यान्वित इंटरफ़ेस में वैकल्पिक गुण होते हैं:

interface NeatMethods {
  hasFilename?(f: string): boolean;
}
class Mine implements NeatMethods {
  // oops
  hasFileName(f: string) { return false; }
}

यह _असफलता से ओवरराइड_ की तुलना में कम महत्वपूर्ण समस्या है, लेकिन यह अभी भी खराब है।

आकस्मिक ओवरराइड

बेस क्लास विधि को साकार किए बिना ओवरराइड करना संभव है

class Base {
  hasFilename(f: string) { return true; }
}
class Derived extends Base {
  // I didn't know there was a base method with this name, so oops?
  hasFilename(f: string) { return true; }
}

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

आकस्मिक any s

यह सोचना आसान है कि ओवरराइड विधियों को उनके आधार के पैरामीटर प्रकार मिलेंगे:

class Base {
  hasFilename(f: string) { return true; }
}
class Derived extends Base {
  // oops
  hasFilename(f) { return f.lentgh > 0; }
}

हमने इन मापदंडों को स्वचालित रूप से टाइप करने का प्रयास किया लेकिन समस्याओं का सामना करना पड़ा। यदि hasFilename को स्पष्ट रूप से override के रूप में चिह्नित किया जाता है तो हम उन समस्याओं को अधिक आसानी से हल करने में सक्षम हो सकते हैं।

पठनीयता

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

संपादक अनुभव

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

गैर समस्याओं

इन्हें उन चीजों के रूप में सूचीबद्ध करना जो या तो एक अलग मुद्दे से संबंधित हैं या बस होने वाली नहीं हैं:

• सटीक हस्ताक्षर मिलान - यह ऐसा कुछ नहीं है जिसे override के साथ मिश्रित किया जाना चाहिए, और इसमें वास्तव में कई अच्छे परिदृश्यों में अवांछित अर्थशास्त्र है
• अपर्याप्त रूप से विदेशी सिंटैक्स (जैसे implements.foo = ... )। यहां बाइक चलाने की जरूरत नहीं है

@RyanCavanaugh मैं उपरोक्त सभी के साथ उस आदेश के बारे में भी सहमत हूं। एक टिप्पणी के रूप में, मुझे नहीं लगता कि override कीवर्ड को "कार्यान्वयन में विफलता" समस्या का समाधान करना चाहिए। जैसा कि मैंने ऊपर कहा, मुझे लगता है कि समस्या को एक अलग टिकट के हिस्से के रूप में एक अलग कीवर्ड (जैसे implements ) द्वारा हल किया जाना चाहिए। ( override का अर्थ super. विधि होना चाहिए)

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

@eggers भले ही अंत में दो कीवर्ड की आवश्यकता हो, शब्दार्थ बहुत समान होंगे और मुझे लगता है कि सुविधाओं पर एक साथ चर्चा की जानी चाहिए।

ओवरराइड का मतलब सुपर होना चाहिए। तरीका

सी # ओवरराइड में (और जरूरी) अमूर्त तरीकों के लिए भी इस्तेमाल किया जा सकता है (बिना .super)। जावा में @override एक विशेषता है। बेशक वे अलग भाषा हैं लेकिन समान खोजशब्दों के साथ आप समान व्यवहार की अपेक्षा करते हैं।

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

मेरा मानना ​​​​है कि, जैसे @eggers ने कहा, कि "लागू करने में विफलता" मुद्दा कुछ बहुत अलग है, और किसी ऐसे तरीके के लिए override कीवर्ड का उपयोग करना अजीब लगेगा जो मूल वर्ग में मौजूद नहीं है। मुझे पता है कि ये अलग-अलग समस्याओं के साथ अलग-अलग भाषाएं हैं, लेकिन सी # override में इंटरफेस के लिए उपयोग नहीं किया जाता है। मैं सुझाव दूंगा, अगर हमें --no-implicit-override ध्वज मिल सकता है, तो इंटरफ़ेस विधियों को इंटरफ़ेस नाम के साथ उपसर्ग करना होगा (जो सी # की तरह दिखता है और इस प्रकार अधिक प्राकृतिक लगता है)।

कुछ इस तरह

interface IBase {
    method1?(): void
}

class Base {
    method2() { return true; }
}

class Test extends Base implements IBase {
    IBase.method1() { }
    override method2() { return true; }
}

मुझे लगता है कि @RyanCavanaugh मूलभूत समस्याओं को सूचीबद्ध करता है। मैं इसे "असहमत क्या हैं" के साथ पूरक करूंगा:

• override माने जाने वाले इंटरफ़ेस से मेल खाने के लिए एक विधि घोषित कर रहा है? उदाहरण के लिए:

    interface IDrawable
    {
        draw?( centerPoint: Point ): void;
    }

    class Square implements IDrawable
    {
        draw( centerPoint: Point ): void; // is this an override?
    }

• एक override माने जाने वाले इंटरफ़ेस से मेल खाने के लिए एक संपत्ति घोषित कर रहा है?

    interface IPoint2
    {
        x?: number;
        y?: number;
    }

    class Circle implements IPoint2
    {
        x: number; // is this an override?
        y: number; // is this an override?
        radius: number;
    }

• क्या उपरोक्त मामलों को संभालने के लिए override कीवर्ड के बजाय किसी प्रकार के implements कीवर्ड की आवश्यकता है, और यह किस रूप में होगा।

@ kevmeister68 असहमति को स्पष्ट रूप से बताने के लिए धन्यवाद।

एक बात: आपको वास्तव में समस्या दिखाने के लिए इंटरफ़ेस सदस्यों को वैकल्पिक बनाना होगा, इस तरह टाइपस्क्रिप्ट कंपाइलर शिकायत करेगा जब कोई फ़ील्ड या विधि लागू नहीं की जाती है, "कार्यान्वयन में विफलता" को हल करना।

@olmobrutall इसके लिए धन्यवाद। मैंने कभी भी वैकल्पिक विधि घोषित नहीं की है - क्या यह हो सकता है (मैं सी # पृष्ठभूमि से आया हूं और ऐसी कोई अवधारणा नहीं है)? सदस्य चर को वैकल्पिक में बदलने के लिए मैंने ऊपर सूचीबद्ध उदाहरणों को अद्यतन किया है - क्या यह बेहतर है?

@ kevmeister68 भी draw विधि IDrawable में :)

@RyanCavanaugh

अपर्याप्त रूप से विदेशी वाक्यविन्यास (उदाहरण के लिए उपकरण.फू = ...)। यहां बाइक चलाने की जरूरत नहीं है

मुझे एक नई अभिव्यक्ति सिखाने के लिए धन्यवाद। मुझे सुविधा के शब्दार्थ में बहुत सी समस्याएं नहीं दिखती हैं:

• यदि विधि मौजूद नहीं है तो हम सभी संकलन-समय त्रुटियां चाहते हैं
• हम सभी संकलन-समय की त्रुटियां चाहते हैं जो प्रकार मेल नहीं खाता।
• हम यह भी चाहते हैं कि पैरामीटर मूल रूप से मूल रूप से टाइप किए गए हों, जैसे लैम्ब्डा एक्सप्रेशन करते हैं।
• हम चाहते हैं कि विधि को ठीक से लिखने के लिए कुछ IDE मदद करें।

अधिकांश समस्याएं वाक्य रचना और उन व्यवहारों पर निर्भर करती हैं जिनका वे अर्थ लगाते हैं:

• इंटरफ़ेस में वैकल्पिक सदस्य बनाम बेस क्लास में सदस्य
• तरीके बनाम फ़ील्ड (पता नहीं लैम्ब्डा कहाँ होगा)

आइए पेड़ की तुलना अधिक आशाजनक वाक्यविन्यासों से करें:

ओवरराइड / इम्प्लीमेंट

class Person{
    dateOfBirth: Date;

    abstract talk();
    walk(){ //...}
}

interface ICanFly{
    fly?();
    altitude?: number;
}


class SuperMan extends Person implements ICanFly {
     dateOfBirth = new Date(); //what goes here?

     override talk(){/*...*/}
     walk = () => {/* force 'this' to be captured*/}  //what goes here

     implements fly() {/*...*/}
     altitude = 1000; //what goes here?
}

लाभ:

• ओओ पृष्ठभूमि वाले प्रोग्रामर के लिए यह स्वाभाविक है।
• extends / implements के साथ तुलना करते समय सही लगता है।

नुकसान:

• क्षेत्र की समस्या का समाधान प्रदान नहीं करता है, कोई भी override या implements सही नहीं लगता है। शायद super. , लेकिन फिर हम इंटरफेस के साथ क्या करते हैं?
• यदि विधियों को function() के लैम्ब्डा (इसे कैप्चर करने के लिए उपयोगी) का उपयोग करके ओवरराइड किया जाता है तो वही समस्याएं होती हैं।

ओवरराइड / InterfaceName.

class Person{
    dateOfBirth: Date;

    abstract talk();
    walk(){ //...}
}

interface ICanFly{
    fly?();
    altitude?: number;
}


class SuperMan extends Person implements ICanFly {
     dateOfBirth = new Date(); //what goes here?

     override talk(){/*...*/}
     walk = () => {/* force 'this' to be captured*/}  //what goes here

     ICanFly.fly() {/*...*/}
     ICanFly.altitude = 1000; //what goes here?
}

लाभ:

• ओओ पृष्ठभूमि वाले प्रोग्रामर के लिए भी स्वाभाविक है।
• इंटरफेस के लिए क्षेत्र की समस्या को हल करता है, लेकिन कक्षाओं के लिए नहीं, लेकिन हम उनके लिए super. का उपयोग कर सकते हैं।

नुकसान:

• इंटरफ़ेस नाम लंबे हो सकते हैं, विशेष रूप से जेनरिक के साथ, और ऑटो-प्रतियोगिता सूची दिखाना भी समस्याग्रस्त होगा, इसे स्पष्ट करने के लिए कुछ Alt + Space की आवश्यकता होगी।
• ऐसा लगता है कि आप अलग-अलग इंटरफेस से एक ही नाम के दो सदस्यों को स्वतंत्र रूप से लागू कर सकते हैं। यह सी # में काम करता है लेकिन जावास्क्रिप्ट में काम नहीं करेगा।

this.

class Person{
    dateOfBirth: Date;

    abstract talk();
    walk(){ //...}
}

interface ICanFly{
    fly?();
    altitude?: number;
}


class SuperMan extends Person implements ICanFly {
     this.dateOfBirth = new Date();

     this.talk(){/*...*/}
     this.walk = () => {/* force 'this' to be captured*/} 

     this.fly() {/*...*/}
     this.altitude = 1000;
}

लाभ:

• कक्षाओं, इंटरफेस, विधियों और क्षेत्रों को हल करता है।
• केवल एक पूर्व-मौजूदा कीवर्ड का उपयोग करता है (दुरुपयोग?)
• स्वतः पूर्णता को ट्रिगर करने के लिए this. का उपयोग करना स्वाभाविक लगता है।
• यह स्पष्ट करता है कि वस्तु केवल एक नामस्थान है, और आपके पास प्रत्येक नाम के लिए केवल एक ही चीज़ हो सकती है।

नुकसान:

• एक अभिव्यक्ति की तरह दिखता है, घोषणा नहीं, जिससे गैर-प्रशिक्षित आंखों के लिए विश्लेषण करना मुश्किल हो जाता है।

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

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

उदाहरण के लिए, ऐसे परिदृश्य पर विचार करें जहां एक डेवलपर _विश्वास_ वे एक इंटरफ़ेस विधि लागू कर रहे हैं जब वास्तव में वे उस विधि को ओवरराइड कर रहे हैं जिसे पहले ही बेस क्लास में घोषित किया जा चुका है। दो खोजशब्दों के साथ संकलक इस तरह की गलती को रोक सकता है और एक त्रुटि को method already implemented in a base class के स्वर में फेंक सकता है।

interface IDelegate {
    execute?() : void;
}

class Base implements IDelegate {
    implement public execute() : void { /// fine, this is correctly implementing execute
    }
}

class Derived extends Base {
    implement public execute() : void { 
/// ERROR: `method "execute():void" already implemented in a base class`
    }
}

मुझे नहीं पता कि यह जेएस में प्रासंगिक है या नहीं, लेकिन ओओ में कक्षा के क्षेत्रों को निजी माना जाता है, इसलिए मुझे नहीं लगता कि हमें स्पष्ट रूप से फ़ील्ड को ओवरराइड करने की आवश्यकता है क्योंकि वे निजी हैं पहले से ही हमें पूरी तरह से ओवरराइड करने से रोकते हैं .

इंस्टेंस विधियां हालांकि फ़ील्ड हैं, और जो कुछ मैं इकट्ठा करता हूं उससे बहुत से लोग प्रोटोटाइप विधियों के बजाय उनका उपयोग करते हैं। उसके बारे में,

class Person{
    walk(){ //...}
}
class SuperMan extends Person  {
     walk = () => {/* force 'this' to be captured*/}
}

एक कंपाइलर त्रुटि है, क्योंकि walk में एक प्रोटोटाइप विधि है और Person SuperMan एक उदाहरण विधि है।

वैसे भी, मुझे यकीन नहीं है कि override यहां फिट होगा, क्योंकि ठीक है, हम फ़ील्ड को ओवरराइड नहीं करते हैं। दोबारा, यह सी# जैसा दिखेगा, लेकिन मैं यहां $ override के बजाय new कीवर्ड का उपयोग करना चाहूंगा। क्योंकि यह विधि ओवरराइड के समान नहीं है (मैं super.myMethod को ओवरराइड में कॉल कर सकता हूं, यहां नहीं)।

मेरा पसंदीदा समाधान तब कुछ ऐसा होगा (मान लीजिए कि हम सख्त ओवरराइड मोड में हैं):

class Person{
    dateOfBirth: Date;
    talk() { }
    walk = () => { }
}

interface ICanFly {
    fly?();
    altitude?: number;
}

class SuperMan extends Person implements ICanFly {
     new dateOfBirth = new Date();
     override talk() { }
     new walk = () => { }

     implements fly() {/*...*/}
     implements altitude = 1000;
}

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

class C extends React.Component {
    implements componentWillMount() { }
    implements componentDidMount() { }
    implements componentWillReceiveProps(props) { }
    /// ... and the list goes on
}

मैंने पहले इंटरफ़ेस नाम के साथ उपसर्ग करने का प्रस्ताव रखा था लेकिन @olmobrutall ने मुझे दिखाया कि यह एक बुरा विचार था।

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

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

क्या new , override और implement अनिवार्य रूप से समान JS सेमेन्टिक्स के लिए बहुत अधिक कीवर्ड ओवरहेड नहीं है? भले ही सी # में वे अलग-अलग चीजें हों, जेएस/टीएस में वर्चुअल कोई अंतर नहीं है।

यह भी काफी अस्पष्ट है:

• कक्षाओं के लिए फ़ील्ड new लेकिन इंटरफेस के लिए implements क्यों हैं?
• यदि आप किसी इंटरफ़ेस के साथ लागू किए गए बेस क्लास से कोई विधि बदल रहे हैं तो आपको क्या उपयोग करना चाहिए? मैं चार संभावनाएं देख सकता हूं: override , implements , दोनों में से कोई एक या दोनों एक ही समय में?

इसके बारे में भी सोचें:

class Animal {
}

class Human extends Animal {
}

class Habitat {
    owner: Animal;
}

class House extends Habitat {
    owner = new Human();
}

var house = new House();
house.owner = new Dog(); //Should this be allowed??  

सवाल यह है की:

क्या owner = new Human(); एक नए (लेकिन संगत) प्रकार के साथ फ़ील्ड को फिर से परिभाषित करता है, या केवल एक मान निर्दिष्ट करता है।

मुझे लगता है कि सामान्य तौर पर आपने फ़ील्ड को फिर से परिभाषित किया है, सिवाय इसके कि आप _magic कीवर्ड_ का उपयोग कर रहे हैं। मेरी प्राथमिकता अभी this. के लिए है।

class House extends Habitat {
    this.owner = new Human(); //just setting a value, the type is still Animal
}

@olmobrutall यह वास्तव में थोड़ा अधिक कीवर्ड ओवरहेड हो सकता है, लेकिन सभी 3 वास्तव में _भिन्न_ चीजें हैं।

• override विधियों (प्रोटोटाइप पर परिभाषित) पर लागू होगा, जिसका अर्थ है कि यह _not_ मूल विधि को मिटा देता है, जो अभी भी super के पीछे पहुंच योग्य है।
• new फ़ील्ड पर लागू होगा, और इसका मतलब है कि मूल फ़ील्ड को नए द्वारा मिटा दिया गया है।
• implements एक इंटरफ़ेस से किसी भी चीज़ पर लागू होगा, और इसका मतलब है कि यह किसी भी चीज़ को मिटाता या प्रतिस्थापित नहीं करता है जो पहले से ही मूल वर्ग में मौजूद है, क्योंकि एक इंटरफ़ेस "मौजूद नहीं है"।

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

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

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

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

new अवधारणा में एक दिलचस्प विचार है, लेकिन यह विशेष कीवर्ड वर्ग तात्कालिकता के साथ भ्रमित हो सकता है, इसलिए यह गलत धारणा दे सकता है कि यह केवल कक्षाओं के लिए काम करेगा, इस तथ्य के बावजूद कि गुणों में आदिम, इंटरफ़ेस, संघ हो सकता है या यहां तक ​​​​कि फ़ंक्शन प्रकार। शायद एक अलग कीवर्ड जैसे reassign वहां बेहतर काम कर सकता है, लेकिन यह समस्या है कि यह एक गलत विचार दे सकता है यदि मूल्य केवल फिर से घोषित किया गया है लेकिन वास्तव में व्युत्पन्न वर्ग में कुछ भी नहीं सौंपा गया है ( new में भी वह समस्या हो सकती है)। मुझे लगता है कि redefine भी दिलचस्प है, लेकिन गलत उम्मीद को जन्म दे सकता है कि 'पुनर्परिभाषित' संपत्ति का आधार आधार से अलग प्रकार भी हो सकता है, इसलिए मुझे यकीन नहीं है .. (_edit: वास्तव में मैंने जांच की और इसका एक अलग प्रकार हो सकता है जब तक कि नया आधार एक का उपप्रकार है, इसलिए यह उतना बुरा नहीं हो सकता है)।

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

बेहतर विचार हो सकते हैं, लेकिन इस समय मेरे पास बस इतना ही है..

मैंने कीवर्ड new प्रस्तावित किया क्योंकि यह इस सटीक सुविधा के लिए एक सी # उपयोग है, लेकिन मैं मानता हूं कि यह सबसे अच्छा नहीं है। implement वास्तव में implements से बेहतर विकल्प है। मुझे नहीं लगता कि हमें इसका उपयोग अमूर्त तरीकों के लिए करना चाहिए क्योंकि वे बेस क्लास का हिस्सा हैं न कि इंटरफ़ेस। override + new -> बेस क्लास, implement -> इंटरफ़ेस। यह अधिक स्पष्ट लगता है।

@JabX

इंस्टेंस फ़ील्ड के साथ प्रोटोटाइप को ओवरराइड करने के बारे में

मैंने जाँच की है और आप सही हैं:

class Person{
    walk(){ //...}
}
class SuperMan extends Person  {
     walk = () => {/* force 'this' to be captured*/}
}

कंपाइलर त्रुटि के साथ विफल: Class 'Person' defines instance member function 'walk', but extended class 'SuperMan' defines it as instance member property.

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

var p = new SuperMan();
p.walk = () => { };

या और भी

class SuperMan extends Person {
    constructor() {
        super();
        this.walk = () => { };
    }
}

लगभग override

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

यह वास्तव में एक तर्क है। override और implements के बीच कम से कम _some_ देखने योग्य अंतर है ... लेकिन काफी नहीं।

override और implements दोनों को prototype super का उपयोग करने में सक्षम होना स्वतंत्र है, क्योंकि आप super.walk() कॉल करते हैं न कि केवल super() , और हर तरीके (ओवरराइड, इम्प्लीमेंट, समाचार और सामान्य परिभाषा) में उपलब्ध है।

class SuperMan extends Person implements ICanFly {
     new dateOfBirth = new Date();
     override talk() { } //goes to prototype
     new walk = () => { }

     implements fly() {/*...*/}  //also goes to the prototype
     implements altitude = 1000;
}

और यदि आप उदाहरण के लिए असाइन करते हैं तो super.walk() का उपयोग करने में सक्षम होना भी काम करता है

class SuperMan extends Person {
    constructor() {
        super();
        this.walk = () => { super.walk(); };
    }

    //or with the this. syntax
    this.walk = () => { super.walk(); };
}

उदाहरण फ़ील्ड से prototype फ़ील्ड को अलग करने का एक स्पष्ट तरीका पहले से ही है और यह = टोकन है।

class SuperMan extends Person implements ICanFly {
     this.dateOfBirth = new Date(); //instance
     this.talk() { } //prototype
     this.walk = () => { } //instance

     this.fly() {/*...*/}  //prototype
     this.altitude = 1000; //instance
}

this. सिंटैक्स के साथ समस्या को और अधिक सुंदर ढंग से हल किया गया है:

• this. का अर्थ है मेरे प्रकार (आधार वर्ग और कार्यान्वित इंटरफेस) की जांच करें।
• = का अर्थ है प्रोटोटाइप के बजाय इंस्टेंस को असाइन करना।

लगभग New

new फ़ील्ड पर लागू होगा, और इसका मतलब है कि मूल फ़ील्ड को नए द्वारा मिटा दिया गया है।

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

class Person {
    walk() { }

    run() {
        this.walk();
        this.walk();
        this.walk();
    }
}

class SuperMan extends Person {
    new walk(destination: string) { } //Even if you write `new` this code will break
}

तो new से अधिक कीवर्ड assign होना चाहिए, क्योंकि यह एकमात्र प्रकार की सुरक्षित चीज है जो आप कर सकते हैं:

class Person{
    dateOfBirth: Date;
}

class SuperMan extends Person implements ICanFly {
     assign dateOfBirth = new Date();
}

ध्यान दें कि reassign का कोई मतलब नहीं है, क्योंकि व्यक्ति केवल क्षेत्र की घोषणा करता है लेकिन उस पर कोई मूल्य निर्धारित नहीं करता है।

assign लिखना बेमानी लगता है, हालांकि, यह स्पष्ट है कि हम असाइन कर रहे हैं क्योंकि हमारे पास दूसरी तरफ = है।

फिर से this. सिंटैक्स समस्या को इनायत से हल करता है:

class Person{
    dateOfBirth: Date;
}

class SuperMan extends Person implements ICanFly {
     this.dateOfBirth = new Date();
}

मुझे यकीन नहीं है कि आप इसे फ़ील्ड में इस तरह से कैसे लागू करते हैं जो समझ में आता है।

हम एक ऐसे कीवर्ड को जोड़ने की बात कर रहे हैं जो केवल क्लास बॉडी में लागू होता है, फिर भी इंस्टेंस के जीवनकाल में फ़ील्ड्स को _any point_ पर फिर से असाइन किया जा सकता है।

टाइपस्क्रिप्ट आपको पहले से ही क्लास बॉडी में फ़ील्ड्स को इनिशियलाइज़ करने की अनुमति देता है:

class Person {
    dateOfBirth : new Date();
}

यह आपको मूल वर्ग में घोषित फ़ील्ड को फिर से प्रारंभ करने की अनुमति देता है, लेकिन स्थिति खराब है। बेशक आप नाम गलत लिख सकते हैं (इसी तरह की समस्या override ) लेकिन प्रकार भी मिटा दिया गया है। इस का मतलब है कि:

class Person {
    fullName: { firstName: string; lastName?: string };
}

class SuperMan extends Person {
    fullName = { firstName: "Clark" };

    bla() {
        this.fullName.lastName; //Error
    }
}

यह कोड विफल रहता है: संपत्ति 'lastName' प्रकार पर मौजूद नहीं है '{ firstName: string;

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

इसके अलावा तरीके:

class Person {
    talk() { }
}

class SuperMan extends Person {

    talk() { }

    changeMe(){
        this.talk = () => { };      
    }

    changeMyPrototype() {
        SuperMan.prototype.talk = () => { };
    }
}

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

@olmobrutall

फ़ील्ड के साथ ओवरराइड करने के तरीकों के बारे में

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

इंटरफेस के बारे में

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

नए के बारे में

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

इसके बारे में।

हालांकि, एकीकृत फ़ील्ड/विधि ओवरराइड सिंटैक्स this.method() या this.field नहीं होना चाहिए क्योंकि यह कुछ ऐसा दिखता है जो वैध जावास्क्रिप्ट हो सकता है, जबकि ऐसा नहीं है। सदस्य के सामने एक कीवर्ड जोड़ना इस तथ्य के प्रति स्पष्ट होगा कि वास्तव में एक टाइपस्क्रिप्ट चीज है।
this हालांकि एक अच्छा विचार है, इसलिए शायद हम बिंदु को छोड़ सकते हैं और कुछ कम अस्पष्ट लिख सकते हैं जैसे

class Superman {
    this walk() { }
}

लेकिन फिर भी यह देखने में थोड़ा अजीब लगता है। और इसे implement के साथ मिलाना थोड़ा हटकर लगेगा (क्योंकि हम इस तथ्य से ठीक हैं कि इस this सिंटैक्स का उपयोग इंटरफ़ेस के साथ नहीं किया जाएगा?), और मुझे implement पसंद है override जोड़ी। फ़ील्ड पर एक override संशोधक अभी भी मुझे परेशान करता है, लेकिन शायद यह बेहतर है कि तीसरा अस्पष्ट new कीवर्ड हो। चूंकि असाइनमेंट ( = ) एक विधि और एक क्षेत्र के बीच अंतर को स्पष्ट करता है, यह अब मेरे द्वारा ठीक होगा (जैसा कि मैं कुछ घंटे पहले कह रहा था)।

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

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

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

हम 150k+ लाइन कोडबेस से अधिक कार्यों के रूप में फ़ील्ड का बहुत ही कम उपयोग करते हैं, इसलिए मुझे लगता है कि यह व्यापक रूप से उपयोग किया जाता है शायद व्यक्तिपरक है।

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

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

मेरा मानना ​​​​है कि जहां तक ​​​​ओवरराइड का संबंध है, फ़ील्ड में वही समस्याएं हैं जो विधियों के रूप में हैं।

class A {
    firstName: string;
    get name() {
        return this.firstName;
    }
}

class B extends A {
    firstname = "Joe" // oops
}

कंस्ट्रक्टर में फ़ील्ड असाइन करना यहाँ एक संभावित समाधान है

class B extends A {
    constructor() {
        this.firstName = "Joe"; // can't go wrong
    }
}

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

मेरा नया प्रस्ताव होगा, और एक अस्थायी member कीवर्ड का उपयोग करना (शायद सबसे अच्छा विकल्प नहीं):

interface IBase {
    interfaceField?: string;
    interfaceMethod(): void
}

abstract class Base {
    baseField: number;
    baseMethod() { }
    baseLambda: () => { };
    abstract baseAbstractMethod();
}

class Derived extends Base implements IBase {
    member interfaceField = "Hello";
    member interfaceMethod() { }
    member baseField = 2;
    override baseMethod() { }
    override baseLambda = () => { };
    member baseAbstractMethod() { }
}

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

मुझे लगता है कि टाइपस्क्रिप्ट जावास्क्रिप्ट का संकलन-समय पर चेक किया गया संस्करण होना चाहिए, और टीएस सीखकर आपको जेएस भी सीखना चाहिए, जैसे सी # सीखने से आपको सीएलआर का अच्छा अंतर्ज्ञान मिलता है।

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

यदि आप विधियों या क्षेत्रों को विरासत में प्राप्त कर रहे हैं तो प्रोटोटाइप विरासत कोई फर्क नहीं पड़ता।

उदाहरण के लिए:

class Rectangle {
       x: number;
       y: number;
       color: string;
}

Rectangle.prototype.color = "black";

यहां हम प्रोटोटाइप ऑब्जेक्ट में एक साधारण फ़ील्ड सेट कर रहे हैं, इसलिए इसके लिए इंस्टेंस फ़ील्ड के बिना सभी आयत डिफ़ॉल्ट रूप से काले होंगे।

class BoundingBox {
      override color = "transparent"; // or should be member? 
}

साथ ही member कीवर्ड वर्ग के अन्य सदस्यों को ईर्ष्यालु बनाता है।

हमें जो चाहिए वह एक सिंटैक्स है जो एक वर्ग घोषणा संदर्भ में उसी तरह के व्यवहार की अनुमति देगा (संकलन समय की जाँच / स्वतः पूर्ण / नाम) जो हमारे पास पहले से ही वस्तु शाब्दिक या सदस्य अभिव्यक्तियों में है।

शायद this. का एक बेहतर विकल्प सिर्फ . है:

class Derived {
   .interfaceField = "hello";
   .interfaceMethod() {}
   .baseField = 2;
   .baseMethod() {}
   .baseLambda = () => {};
   .baseAbstractMethod(){};

   someNewMethod(){}
   someNewField = 3;
}

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

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

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

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

@olmobrutall
ES6 कक्षाएं पहले से ही प्रोटोटाइप सामग्री को छिपा रही हैं, और जैसे @kungfusheep ने कहा, इसके साथ सीधे खिलवाड़ करना बिल्कुल सामान्य बात नहीं है।

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

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

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

@RyanCavanaugh

यह override . के संदर्भ में स्पर्शरेखा से बहुत सुंदर है

ओवरराइड के साथ मेरी समस्या यह है कि इंटरफ़ेस विधियों और क्षेत्रों के लिए पर्याप्त सामान्य नहीं है। मुझे तीन विकल्प दिखाई देते हैं:

• केवल बेस क्लास विधियों के लिए override का उपयोग करें।
• इंटरफ़ेस विधियों और क्षेत्रों के लिए भी override का उपयोग करें
• वैकल्पिक सिंटैक्स पर विचार करें ( member , implement , this. , . , आदि...)
• कुछ मत करो (यह दुखद होगा)

मुझे लगता है कि यह फैसला यहीं लिया जाना चाहिए।

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

बिल्कुल! हम सभी ट्रांसपिलिंग की वर्तमान स्थिति से खुश हैं, लेकिन टाइप-चेकिंग/टूलिंग पर नहीं।

कीवर्ड जो भी हो, वह केवल टाइपस्क्रिप्ट होगा (बस सार के रूप में)

@JabX

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

class Person {
    name: string = "John"; 

    saySomething() {
        return "Hi " + this.name;
    }
}

हम एक वर्ग की घोषणा करते हैं, name उदाहरण के लिए जाएगा जबकि saySomething प्रोटोटाइप के लिए। फिर भी मैं यह लिख सकता हूँ:

Person.prototype.name = "Unknown"; 

क्योंकि Person.prototype का प्रकार संपूर्ण व्यक्ति है। टाइपस्क्रिप्ट सरलता के लिए उसके टाइप सिस्टम पर क्या जाता है इसका ट्रैक नहीं रखता है।

हर चीज के लिए एक यूनिक कीवर्ड होना अच्छा हो सकता है लेकिन इसके अर्थ के बारे में बहुत स्पष्ट होना चाहिए।

जो मुझे लगता है वह अधिक महत्वपूर्ण है और हम सभी सहमत हो सकते हैं शब्दार्थ:

संशोधित XXX जांचता है कि सदस्य पहले से ही बेस क्लास या कार्यान्वित इंटरफेस में घोषित किया गया है, आमतौर पर बेस क्लास से कार्यों को ओवरराइड करने के लिए उपयोग किया जाता है।

चूंकि . या this. बहुत अलग दिखते हैं, और member बेमानी है, मुझे लगता है कि शायद सबसे अच्छा विकल्प सभी मामलों के लिए override का दुरुपयोग करना है । फ़ील्ड सेट करना या इंटरफ़ेस विधियों को लागू करना वैसे भी एक साइड-फीचर है।

कई मिसालें हैं:

• सी # में एक static class वास्तव में वस्तुओं का _class नहीं है।
• static फ़ील्ड के बारे में _static_ कुछ भी नहीं है।
• virtual विधियां काफी _concrete_ हैं (वीबी Overrideable का उपयोग करती है)।

यह इस तरह दिखेगा:

class Person{
    dateOfBirth: Date;

    abstract talk();
    walk(){ //...}
}

interface ICanFly{
    fly?();
    altitude?: number;
}


class SuperMan extends Person implements ICanFly {
     override dateOfBirth = new Date();

     override talk(){/*...*/}
     override walk = () => {/* force 'this' to be captured*/} 

     override  fly() {/*...*/}
     override altitude = 1000; 
}

क्या हम उस पर समझौता कर सकते हैं?

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

लेकिन implement और override के बीच कोई अर्थपूर्ण अंतर नहीं है।

दोनों के पास जेएस के समान ऑटो-पूर्ण/त्रुटि संदेश/ट्रांसपिलेशन होने जा रहे हैं ... यह सिर्फ एक दार्शनिक अंतर है।

यह वास्तव में दो कीवर्ड की व्याख्या करने लायक है और एक पेडेंटिंग कंपाइलर आपको बताता है: Error you should use 'override' instead of 'implement' ।

इस मामले के बारे में क्या:

interface IComparable {
     compare(): number;
} 

class BaseClass implements IComparable {
    implement compare(); 
}

class ChildClass extends BaseClass implements IComparable { //again 
     override compare(); // or implements... 
}

सवाल है... कौन परवाह करता है?.

इसके अलावा implement / implements मुद्दा भी है।

आइए केवल override का दुरुपयोग करें। एक अवधारणा एक कीवर्ड, यह महत्वपूर्ण बात है।

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

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

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

ज़रूर, मैं सिर्फ इतना कहना चाहता था कि चार मामले हैं। बेस क्लास, इंटरफेस, बेस क्लास में इंटरफेस, बेस क्लास में इंटरफेस को फिर से लागू करें।

@JabX

मुझे नहीं लगता कि किसी अभिभावक वर्ग पर घोषित नहीं की गई किसी चीज़ पर ओवरराइड करने का कोई मतलब नहीं होगा। लेकिन शायद मैं अकेला हूं जो भेद चाहता है ।

आप नहीं हैं। वे दो मौलिक रूप से भिन्न चीजें हैं और भाषा के स्तर पर उस अलगाव के होने में लाभ है।

मुझे लगता है कि अगर इस नई कार्यक्षमता में इंटरफेस का समर्थन किया जाना है तो यह कुछ आधा बेक्ड समाधान नहीं हो सकता है जिसे override पर बोल्ट किया गया है। इसी कारण से extends वर्ग स्तर पर implements के लिए एक अलग इकाई के रूप में मौजूद है, override implement की तर्ज पर किसी चीज़ के साथ जोड़ा जाना चाहिए इस समस्या को ठीक करने के लिए। यह _कार्यक्षमता को बदल रहा है_ बनाम _कार्यक्षमता को परिभाषित कर रहा है_।

@olmobrutall

यह वास्तव में दो कीवर्ड की व्याख्या करने लायक है और एक पेडेंटिंग कंपाइलर आपको बताता है: त्रुटि आपको 'कार्यान्वयन' के बजाय 'ओवरराइड' का उपयोग करना चाहिए।

मुझे ऐसा लगता है कि मैंने यह अंतर अब लगभग 4 बार किया है, लेकिन यह पांडित्यपूर्ण नहीं है; यह वास्तव में महत्वपूर्ण जानकारी है!

अपने स्वयं के उदाहरण पर विचार करें

interface IComparable {
     compare(): number;
} 

class BaseClass implements IComparable {
    implement compare(); 
}

class ChildClass extends BaseClass implements IComparable { //again 
     override compare(); // or implements... 
}

इस मामले में 'या उपकरण...' पूरी तरह से गलत धारणा है। सिर्फ इसलिए कि आपने संकलक को बताया है कि आप उसी इंटरफ़ेस को लागू करना चाहते हैं जिस आधार वर्ग को आप विस्तारित कर रहे हैं, इस तथ्य को नहीं बदलता है कि आपने पहले ही compare लागू कर दिया है।
यदि आप $#$8 override #$ के बजाय चाइल्डक्लास में implement लिखते हैं तो आपको आभारी होना चाहिए कि संकलक तब आपको आपकी गलत धारणा के बारे में बताएगा, क्योंकि यह एक बड़ी बात है कि आप अनजाने में पोंछने वाले थे पहले से लागू की गई विधि से बाहर!

कोडबेस में जिसके लिए मैं जिम्मेदार हूं, बिना किसी संदेह के एक बड़ी समस्या होगी; इसलिए मैं किसी भी कंपाइलर सुविधा का स्वागत करता हूं जो ऐसी किसी भी डेवलपर गलतियों को रोक सके!

@ कुंगफुशीप

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

यदि पहले से लागू की गई विधि को ओवरराइड करना इतना महत्वपूर्ण निर्णय है तो implement का उपयोग अमूर्त विधियों के लिए भी किया जाना चाहिए। यदि आप किसी विधि को abstract से virtual में बदलते हैं या आपके आस-पास के अन्य तरीकों को super पर कॉल करने या केवल विधि को हटाने पर विचार करने के लिए सभी कार्यान्वित संस्करणों की जांच (और परिवर्तन) करनी चाहिए।

व्यवहार में यह C# में कभी कोई समस्या नहीं रही है।

मैं सहमत हूं, कार्यान्वित विधियों के लिए override , और implements लागू नहीं किए गए तरीकों (सार/इंटरफ़ेस) के लिए।

इसका उपयोग सार के लिए किया जा सकता है, हाँ।

सी # में 'वैकल्पिक' इंटरफ़ेस परिदृश्य नहीं था, इसलिए शायद इसे किसी समस्या के रूप में नहीं समझा गया था।

लेकिन मेरा कहना यह है कि C# में हमने override लागू किए और लागू नहीं किए गए तरीके और मैंने कभी किसी को शिकायत करते हुए नहीं सुना।

मुझे नहीं लगता कि यह वास्तव में एक ऐसा मुद्दा है जो सुविधा को कम से कम दो गुना कठिन समझाने के योग्य है।

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

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

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

@JabX मैं व्यक्तिगत रूप से एक चेतावनी चाहता हूं यदि बेस क्लास ने एक अमूर्त विधि के कार्यान्वयन को जोड़ा।

हालांकि, मैं पहली बार में एक इम्प्लीमेंट्स कीवर्ड के विचार पर 100% बिका नहीं हूं। यदि आपने कुछ लागू नहीं किया है तो संकलक आपको पहले ही चेतावनी देगा। वैकल्पिक तरीकों के लिए यह एकमात्र जगह है जो वास्तव में सहायक है।

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

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

मुझे लगता है कि इसे नहीं लिखना एक चेतावनी होनी चाहिए।

वैकल्पिक तरीकों के लिए यह एकमात्र जगह है जो वास्तव में सहायक है।

हाँ, यह यहाँ पूरी बात है।

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

यह चेतावनी या कुछ भी हो सकता है लेकिन वर्तमान में यह बहुत दर्दनाक है।

मैं alm.tools में UML वर्ग दृश्य में ओवरराइड एनोटेशन जोड़ रहा हूं: गुलाब:

रेफरी https://github.com/alm-tools/alm/issues/84

मैंने कक्षा के सदस्यों के लिए एक गटर संकेतक भी जोड़ा है जो alm में बेस क्लास सदस्य को ओवरराइड करता है।

रेफरी https://github.com/alm-tools/alm/issues/111

हमें लगता है कि एक सीमित समाधान के लिए पीआर को स्वीकार करना कम से कम जटिलता के साथ सबसे अधिक मूल्य प्राप्त करता है:

• नया कीवर्ड override वर्ग विधि और संपत्ति घोषणाओं पर मान्य है (प्राप्त/सेट सहित)
  
  
  
  • सभी हस्ताक्षर (कार्यान्वयन सहित) में override होना चाहिए यदि कोई करता है
  
  
  • get और set दोनों को override चिह्नित किया जाना चाहिए यदि दोनों में से कोई एक है
  
  
• यदि इस नाम के साथ कोई बेस क्लास प्रॉपर्टी/विधि नहीं है तो override होना एक त्रुटि है
• नया कमांडलाइन स्विच --noImplicitOverride (यहां नाम को बेझिझक बाइकशेड महसूस करें) override को उन चीजों के लिए अनिवार्य बनाता है जो ओवरराइड हैं
  
  
  
  • इस स्विच का परिवेशी संदर्भों में कोई प्रभाव नहीं है (अर्थात declare class या .d.ts फ़ाइलें)
  
  

इस समय दायरे से बाहर:

• इनहेरिटिंग सिग्नेचर
• पैरामीटर या इनिशियलाइज़र की प्रासंगिक टाइपिंग (पहले यह कोशिश की गई थी और यह एक आपदा थी)
• "मैं इस घोषणा के साथ एक इंटरफ़ेस सदस्य को लागू कर रहा हूं" इंगित करने के लिए संबंधित कीवर्ड

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

सभी हस्ताक्षर (कार्यान्वयन सहित) में override होना चाहिए यदि कोई करता है

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

class A {
    method() {}
}

class B extends A {
    override method() {}
}

class C extends B {
    method() {} 
}

कक्षा सी में त्रुटि उत्पन्न करनी चाहिए क्योंकि मैंने method से पहले method override नहीं लिखा था?

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

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

मेरे पास . के बारे में एक और सवाल है

get और set दोनों को override के रूप में चिह्नित किया जाना चाहिए यदि दोनों में से कोई एक है

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

class A {
    get value() { return 1; }
}

class B extends 1 {
   override set value(v: number) {}
}

जो मुझे सादा गलत लगता है।

चूंकि आपके पास कक्षा में किसी विधि के एकाधिक हस्ताक्षर नहीं हो सकते हैं

आपके पास एक ही विधि के लिए एकाधिक अधिभार हस्ताक्षर हो सकते हैं:

class Base { bar(): { } }

class Foo extends Base {
  // Must write 'override' on each signature
  override bar(s: string): void;
  override bar(s?: number): void;
  override bar(s: string|number) { }
}

मुझे लगता है कि अन्य मामलों के बारे में आपका अंतर्ज्ञान सही है।

गेटर्स और सेटर्स के संबंध में, मुझे लगता है कि override सिर्फ संपत्ति स्लॉट पर लागू होता है। एक संबंधित गेटर के बिना एक ओवरराइडिंग सेटर लिखना स्पष्ट रूप से बेहद संदिग्ध है, लेकिन override की उपस्थिति में यह कम या ज्यादा संदिग्ध नहीं है। चूंकि हम हमेशा नहीं जानते कि बेस क्लास कैसे लागू किया गया था, मुझे लगता है कि नियम बस इतना है कि override गेट्टर या सेटर के पास _some_ संबंधित बेस क्लास प्रॉपर्टी होनी चाहिए, और यदि आप override get { कहते हैं , किसी भी set घोषणा में override भी होना चाहिए (और इसके विपरीत)

ओह ठीक है, मुझे नहीं पता था कि हम इस तरह की कक्षाओं में विधि हस्ताक्षर लिख सकते हैं, यह बहुत साफ है।

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

कृपया इन्हें प्राथमिकता दें। धन्यवाद!

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

"वर्चुअल", "ओवरराइड" और "फाइनल" सही होगा।

यह मेरे लिए एक महत्वपूर्ण मुद्दा है।

@RyanCavanaugh

पैरामीटर या इनिशियलाइज़र की प्रासंगिक टाइपिंग (पहले यह कोशिश की गई थी और यह एक आपदा थी)

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

@pankleks

मुझे लगता है कि virtual भी समझ में आएगा।

इसकी प्रकृति से जेएस में सब कुछ "आभासी" है। final के लिए समर्थन IMHO के लिए पर्याप्त होगा: यदि आपके पास कोई विधि (या संपत्ति) है जिसे ओवरराइड नहीं किया जाना चाहिए, तो आप इसका उल्लंघन होने पर कंपाइलर त्रुटि को ट्रिगर करने के लिए इसे चिह्नित कर सकते हैं। फिर virtual की कोई आवश्यकता नहीं है, है ना? लेकिन इसे अंक #1534 में ट्रैक किया गया है।

@avonwyss यहाँ दो तरह के मुद्दे हैं।

जब हमने प्रासंगिक रूप से _property इनिशियलाइज़र_ टाइप करने का प्रयास किया, तो हमें https://github.com/Microsoft/TypeScript/pull/6118#issuecomment -216595207 पर वर्णित कुछ समस्याओं का सामना करना पड़ा। हमें लगता है कि #10570 . पर हमारे पास एक नया और अधिक सफल दृष्टिकोण है

विधि घोषणाएं मोम की एक अलग गेंद होती हैं और वहां हमें कुछ अन्य चीजों का पता लगाना होता है, जैसे कि यहां क्या होना चाहिए:

declare class Base {
  method(x: string): string[];
  method(x: number, count: number): number[];
}
class Derived extends Base {
  method(x) { // x: ???
    return x;
  }
}

हम केवल यह तय कर सकते हैं कि केवल एकल-हस्ताक्षर विधियों को आधार से पैरामीटर प्रकार मिलते हैं। लेकिन यह हर किसी को खुश करने वाला नहीं है और वास्तव में "मैं चाहता हूं कि मेरी व्युत्पन्न कक्षा को समान _signatures_ लेकिन केवल एक अलग _कार्यान्वयन_ प्रदान करें" की लगातार समस्या का समाधान नहीं करता है।

ठीक है, उस मामले में x का प्रकार string | number होगा, लेकिन मैं समझता हूं कि लगातार पता लगाना काफी कठिन हो सकता है।

लेकिन आप शायद नहीं चाहेंगे कि x का _externally-seen_ प्रकार string | number हो - यह मानते हुए कि Derived में Base के समान शब्दार्थ है, यह होगा' (3) या ('foo', 3) . के साथ आह्वान करना कानूनी नहीं है

हम हाँ, मुझे वह याद आया।

मुझे लगता है कि आपने इसे एकल-हस्ताक्षर विधियों तक सीमित करने का सुझाव दिया है, लेकिन मेरा मानना ​​​​है कि इसे "आसानी से" "मिलान-हस्ताक्षर" विधियों में विस्तारित किया जा सकता है, जैसे आपके उदाहरण में:

declare class Base {
  method(x: string): string[];
  method(x: number, count: number): number[];
}
class Derived extends Base {
  method(x, count) { // x: number, count: number
    return [];
  }
}

क्योंकि मिलान करने वाले बेस क्लास पर केवल हस्ताक्षर पर है।

यह हमारे पास (कुछ नहीं) की तुलना में बेहतर होगा, और मुझे नहीं लगता कि यह करना मुश्किल होगा? (अभी भी इस मुद्दे के दायरे से बाहर है और शायद अधिक काम)

@RyanCavanaugh उत्तर के लिए धन्यवाद। जैसा कि override के लिए मेरी आशा का उल्लेख किया गया है कि यह पैरामीटर (और वापसी प्रकार) को हल करेगा। लेकिन मैं आपके उदाहरण को समस्याग्रस्त के रूप में नहीं देखता, क्योंकि ओवरलोड में हमेशा एक "निजी" कार्यान्वयन होता है जो सभी ओवरलोड के साथ संगत होता है (यही कारण है कि @JabX का सुझाव अवधारणात्मक रूप से काम नहीं करेगा)।
तो, हमारे पास कुछ ऐसा होगा:

declare class Base {
  method(x: string): string[];
  method(x: number, count: number): number[];
  // implies: method(x: string|number, count?: number): string[]|number[]
  // or fancier: method<T extends string|number>(x: T, count?: number): T[]
}
class Derived extends Base {
  override method(x, count?) { // may only be called like the method on Base
    return [x];
  }
}

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

ओवरराइड करने के लिए डिज़ाइन की गई विधियों में आमतौर पर किसी भी तरह से ओवरलोड नहीं होता है, इसलिए यहां तक ​​​​कि सरल तरीका निकालना और पैरामीटर का अनुमान नहीं लगाना और ओवरलोड मौजूद होने पर रिटर्न प्रकार पूरी तरह से ठीक और उपयोगी होगा। तो अगर व्यवहार अतिभारित विधियों को ओवरराइड करते समय जैसा था, तो आपको --no-implicit-any मोड में चलते समय एक त्रुटि मिल जाएगी और आपको संगत प्रकार निर्दिष्ट करना होगा, जो एक बिल्कुल ठीक दृष्टिकोण की तरह प्रतीत होता है।

मुझे शायद कुछ याद आ रहा है, लेकिन जावास्क्रिप्ट (और इस प्रकार टाइपस्क्रिप्ट) में आपके पास एक ही नाम के साथ 2 विधियां नहीं हो सकती हैं - भले ही उनके पास अलग-अलग हस्ताक्षर हों?

सी # में, आपके पास हो सकता है

public string method(string blah) {};
public int method(int blah) {};

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

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

@ सैम-एस 4 एस हां एक विधि के लिए एकाधिक तार्किक अधिभार हस्ताक्षर घोषित करना संभव है, लेकिन वे सभी एक ही कार्यान्वयन पर समाप्त होते हैं (जिसे तब पारित पैरामीटर द्वारा पता लगाना होता है जिसे "अधिभार" कहा जा रहा है)। इसका उपयोग कई JS फ्रेमवर्क द्वारा किया जाता है, उदाहरण के लिए jQuery जहां $(function) एक तैयार फ़ंक्शन जोड़ता है, लेकिन $(string) चयनकर्ता द्वारा DOM की खोज करता है।

डॉक्स के लिए यहां देखें: https://www.typescriptlang.org/docs/handbook/functions.html#overloads

@avonwyss आह हाँ, घोषणाएं, लेकिन कार्यान्वयन नहीं, यह समझ में आता है :) धन्यवाद

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

हम कहां हैं (ए) एक override कीवर्ड या (बी) एक @override jsdoc एनोटेशन जो संकलक को सूचित करता है "एक ही नाम और प्रकार के हस्ताक्षर वाले एक विधि सुपरक्लास पर मौजूद होना चाहिए।" ?

अधिक विशेष रूप से, @RyanCavanaugh द्वारा https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -224776519 (जून 8 2016) में टिप्पणी से पता चलता है कि अगला कदम एक (समुदाय) पीआर है?

class Bar extends Foo {
  /**
   * <strong i="12">@override</strong>
   */
  public toString(): string {
     // ... 
  }

  override public toString(): string {
    // ...
  }
}

अधिक विशेष रूप से, @RyanCavanaugh द्वारा #2000 (टिप्पणी) (8 जून 2016) में टिप्पणी से पता चलता है कि अगला कदम एक (समुदाय) पीआर है?

@पीसीजे सही

मैंने इस पर #13217 पर एक जनसंपर्क शुरू किया है। इस कार्यक्षमता में रुचि रखने वाला कोई भी व्यक्ति भाग लेने और/या सुझाव देने के लिए स्वागत करता है। धन्यवाद!

मैं एक डेकोरेटर के साथ जावा के समान ही पसंद करूंगा

<strong i="6">@Override</strong>
public toString(): string {
   // ...
}

@ क्रिस2011 सहमत हैं कि यह परिचित लग रहा है, लेकिन यह एक सजावटी के रूप में इंगित करेगा कि @Override का मूल्यांकन रनटाइम पर किया जाएगा, संकलन-समय पर नहीं। एक बार #13217 ओवरराइड कीवर्ड ( public override toString() ) समीक्षा में आगे बढ़ने के बाद मैं एक अलग पीआर में javadoc /** <strong i="7">@override</strong> */ की योजना बना रहा हूं।

इस सूत्र की बातचीत का अनुसरण करने का प्रयास कर रहा हूं। क्या इसमें स्थिर कार्य शामिल हैं? मुझे कोई कारण नहीं दिख रहा है कि हम व्युत्पन्न कक्षाओं में पूरी तरह से अलग हस्ताक्षर वाले स्थैतिक कार्यों को ओवरराइड करने की अनुमति क्यों नहीं दे सके। यह ES6 में समर्थित है। अगर class A { } ; A.create = function (){} था तो class B extends A { } ; B.create = function (x,y) { } , A.create() पर कॉल करने से B.create() पर कॉल नहीं होगी और समस्याएं पैदा नहीं होंगी। इस कारण से (और फ़ैक्टरी फ़ंक्शंस के रूप में समान फ़ंक्शन नाम का उपयोग करने की क्षमता बनाने के लिए) आपको बेस स्टैटिक फ़ंक्शंस के हस्ताक्षर को ओवरराइड करने की भी अनुमति देनी चाहिए। यह कुछ भी नहीं तोड़ता है, और कुछ साफ-सुथरी चीजें करने की क्षमता जोड़ता है (विशेष रूप से गेम इंजन ढांचे के लिए, जहां जीसी फ्रीज को कम करने के लिए वस्तुओं के कैश से खींचे बिना हर समय उपयोग किए जाने पर 'नया' कुछ भी वास्तव में एक बुराई है)। चूंकि ES6 के तहत कॉल करने योग्य कंस्ट्रक्टर समर्थित नहीं हैं, इसलिए प्रकारों पर विधियों के लिए एक सामान्य नामकरण सम्मेलन बनाना ही एकमात्र अन्य विकल्प है; हालांकि, ऐसा करने के लिए वर्तमान में व्युत्पन्न स्थैतिक फ़ंक्शन की आवश्यकता होती है ताकि आधार स्थिर फ़ंक्शन हस्ताक्षर के अधिभार को स्वयं के साथ दिखाया जा सके, जो कि उस प्रकार के फ़ैक्टरी फ़ंक्शन के लिए उपयोगी नहीं है जो केवल उस प्रकार से संबंधित है। :/ इस बीच मेरे पास एकमात्र विकल्प है कि मैं अपने ढांचे के उपयोगकर्ताओं को सभी आधार पदानुक्रम स्थिर फ़ंक्शन हस्ताक्षर (जैसे SomeType.create() ) को उनके व्युत्पन्न प्रकारों पर डुप्लिकेट करने के लिए मजबूर करूं, और इसी तरह, जो वास्तव में मूर्खतापूर्ण हो जाता है .

यहां "मूर्खता" के बारे में एक उदाहरण दिया गया है जिसके बारे में मैं बात कर रहा हूं (जो काम करता है, लेकिन ऐसा कुछ नहीं है जिस पर मुझे एक एक्स्टेंसिबल फ्रेमवर्क में गर्व होगा):

class A {
    static create(s: string) {
        var inst: A;
        /* new or from cache */
        inst.init(s);
    }
    protected init(s: string) { }
}

class B extends A {
    static create(s: string);
    static create(n: number);
    static create(n:any) {
        var inst: B;
        /* new or from cache */
        inst.init(n);
    }
    protected init(s: string);
    protected init(n: number);
    protected init(n: any) {
        super.init(n.toString());
    }
}

class C extends B {
    static create(s: string)
    static create(n: number)
    static create(b: boolean)
    static create(b: any) {
        var inst: C;
        /* new or from cache */
        inst.init(b);
    }
    protected init(s: string);
    protected init(n: number);
    protected init(b: boolean);
    protected  init(b: any) {
        super.init(b ? 0 : 1);
    }
}

(https://goo.gl/G01Aku)

यह बहुत अच्छा होता:

class A {
    static create(s: string) {
        var inst: A;
        /* new or from cache */
        inst.init(s);
    }
    protected init(s: string) { }
}

class B extends A {
    new static create(n:number) {
        var inst: B;
        /* new or from cache */
        inst.init(n);
    }
    new protected init(n: number) {
        super.init(n.toString());
    }
}

class C extends B {
    new static create(b: boolean) {
        var inst: C;
        /* new or from cache */
        inst.init(b);
    }
    new protected  init(b: boolean) {
        super.init(b ? 0 : 1);
    }
}

@rjamesnw आपको पॉलीमॉर्फिक "इस" में रुचि हो सकती है, स्थिर सदस्यों के लिए कारखाने के कार्यों के लिए अनुबंध करने वाले सभी टिप्पणियों में प्राथमिक उपयोग के मामले के रूप में चर्चा की जाती है।

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

ऐसा लगता है कि # 13217 इतना करीब था, फिर @DanielRosenwasser और कंपनी द्वारा एक ऐसी सुविधा के रूप में फिर से गोली मार दी गई जो भाषा में फिट नहीं हो सकती है, इस मुद्दे पर यहां सर्कुलर वार्तालाप में फिर से प्रवेश कर रहा है कि यह किया जाना चाहिए या नहीं। शायद यह 'डिज़ाइन-टाइम' डेकोरेटर (#2900) चीज़ इसे हल कर देगी, शायद नहीं? जानकर अच्छा लगेगा।

यहां कुछ साल पहले पोस्ट किए गए रनटाइम डेकोरेटर दृष्टिकोण की कुछ और कमियां हैं जिनका मैंने उल्लेख नहीं किया है:

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

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

सच कहूं तो मुझे विश्वास नहीं हो रहा है कि जब से मैंने पहली बार इस मुद्दे को लॉग किया है, तब से यह सुविधा 3 वर्षों में इतनी विवादास्पद है। प्रत्येक "गंभीर" वस्तु उन्मुख भाषा इस कीवर्ड का समर्थन करती है, सी #, एफ #, सी ++ ... आप इसे नाम दें।

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

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

माना। यह देखना निराशाजनक है कि कैसे अपेक्षाकृत अस्पष्ट/किनारे-केस सुविधाओं को जोड़ा जा रहा है, जबकि कुछ ऐसा है ... मौलिक को खारिज कर दिया जा रहा है। क्या इस पर जोर देने के लिए हम कुछ कर सकते हैं?

चलो करते हैं! अगर इतनी सारी टिप्पणियाँ हैं और तीन साल से अधिक समय से, इसे पहले से ही लागू क्यों नहीं किया गया है!

चलो :joy_cat:

कृपया रचनात्मक और विशिष्ट बनें; हमें दर्जनों की जरूरत नहीं है कृपया इसे पहले ही कर लें

लेकिन दोस्तों, कृपया अपने पक्ष में भी विशिष्ट रहें।

स्पष्ट रूप से समुदाय उस विशेषता में बहुत रुचि रखता है, और TS टीम हमें इसके भविष्य के बारे में कोई विवरण नहीं देती है।

मैं व्यक्तिगत रूप से @armandn से पूरी तरह सहमत हूं, टीएस की हालिया रिलीज अपेक्षाकृत कम ही उपयोग की जाने वाली सुविधाओं को लाती है जबकि ऐसा कुछ आयोजित किया जा रहा है।

यदि आप इसे करने की योजना नहीं बनाते हैं, तो बस हमें बताएं। अन्यथा कृपया हमें बताएं कि समुदाय कैसे मदद कर सकता है।

https://github.com/Microsoft/TypeScript/pull/24626 भी।

यहाँ सिर्फ एक समयरेखा है क्योंकि GitHub लोड पर प्रदर्शित करने के लिए तैयार है की तुलना में अधिक टिप्पणियाँ हैं:

• प्रारंभिक मुद्दा खोला गया था
• हमने इसकी समीक्षा की और जटिलता बनाम मूल्य के आधार पर इसे अस्वीकार कर दिया https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -98874744
• #6118 काम करने में विफल होने के बाद हमने इसे फिर से खोल दिया https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -216626012
• हमने कहा कि हम कुछ निर्णय लेने के बाद एक पीआर स्वीकार करेंगे https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -224776519
• पीआर #13217 . पर खुला
• पीआर (लगभग 100 टिप्पणियों) की व्यापक समीक्षा के बाद हम जटिलता चिंताओं #20724 के कारण इसे डिजाइन मीटिंग में वापस ले गए
• फिर से, हमने तय किया कि सुविधा के लाभ जटिलता से अधिक नहीं हैं

ऐसा नहीं है कि हम यहां विचार नहीं कर रहे हैं। यह उतना ही करीब है जितनी सुविधाओं में जाना है, और हमने समान आधार पर अपने स्वयं के फीचर विचारों को अस्वीकार कर दिया है - हाल के उदाहरण के लिए #24423 देखें।

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

अगर मुझे अभी override के साथ मूल समस्याओं को संक्षेप में प्रस्तुत करना है:

• यह आपको ऐसा कुछ भी नहीं करने देता जो आप आज एक डेकोरेटर के साथ नहीं कर सकते (इसलिए यह "नया नहीं" है "जो चीजें आप पूरा कर सकते हैं" के संदर्भ में)
• शब्दार्थ अन्य भाषाओं में override के साथ ठीक से संरेखित नहीं हो सकता (संज्ञानात्मक भार बढ़ाता है)
• यह एक नए कमांडलाइन ध्वज के बिना 100% "प्रकाश" नहीं करता है, और यह एक ध्वज होगा जिसे हम शायद strict के तहत रखना चाहते हैं लेकिन वास्तविक रूप से ऐसा नहीं कर सका क्योंकि यह बहुत बड़ा होगा एक ब्रेकिंग परिवर्तन (वितरित मूल्य घटाता है)। और जो कुछ भी एक नए कमांडलाइन ध्वज का तात्पर्य है, वह कॉन्फ़िगरेशन स्थान का एक और दोहरीकरण है जिसे हमें गंभीरता से तौलने की आवश्यकता है, क्योंकि आप भविष्य के निर्णय लेते समय अपने संपूर्ण मानसिक बजट का उपभोग करने से पहले केवल कई बार किसी चीज़ को दोगुना कर सकते हैं
• यहां इस बारे में काफी मजबूत आंतरिक असहमति है कि क्या override एक इंटरफ़ेस सदस्य को लागू करने के लिए लागू हो सकता है (कथित मूल्य कम हो जाता है क्योंकि उम्मीदें लोगों के कुछ अनुपात के लिए वास्तविकता से मेल नहीं खाती हैं)

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

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

यह आपको ऐसा कुछ भी नहीं करने देता जो आप आज एक डेकोरेटर के साथ नहीं कर सकते (इसलिए यह "नया नहीं" है "जो चीजें आप पूरा कर सकते हैं" के संदर्भ में)

हो सकता है कि मैं इसे गलत समझ रहा हूं, लेकिन बहुत महत्वपूर्ण चीजें हैं जो एक डेकोरेटर वह नहीं कर सकता जो कीवर्ड कर सकता था। मैंने कुछ का उल्लेख https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -389393397 में किया है। यदि वे चीजें संभव हैं तो मुझे निश्चित रूप से सही करें, क्योंकि मैं डेकोरेटर दृष्टिकोण का उपयोग करना चाहता हूं लेकिन गैर-सार विधियां इस सुविधा के लिए मेरे उपयोग के मामले का केवल एक छोटा सा हिस्सा हैं।

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

मेरी धारणा यह है कि एक टीएसलिंट नियम यहां आगे बढ़ने का सबसे आसान रास्ता होगा। @kungfusheep ने संक्षेप में https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -192502734 में इस विचार का उल्लेख किया है, लेकिन मुझे कोई फॉलो-अप नहीं दिख रहा है। क्या किसी और को इस सुविधा के TSLint कार्यान्वयन के बारे में पता है? यदि नहीं, तो मौका मिलने पर मैं शायद एक को हैक करना शुरू कर दूंगा। मैं

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

किसी भी भाग्य के साथ, एक कस्टम TSLint नियम 90% समाधान होगा, केवल वास्तव में सौंदर्यशास्त्र की कमी होगी, और निश्चित रूप से यह भाषा के किसी भी विवरण के बिना आगे बढ़ सकता है। टाइप-अवेयर नियमों, tslint-भाषा-सेवा और ऑटो-फिक्सिंग के साथ, TSLint त्रुटि और डेवलपर के दृष्टिकोण से एक अंतर्निहित TS त्रुटि के बीच वास्तव में बहुत अधिक अंतर नहीं है। मेरी आशा है कि एक TSLint प्लगइन (या कई प्रतिस्पर्धी प्लगइन्स) समुदाय को कुछ अनुभव और सर्वोत्तम शब्दार्थ पर एक समझौते पर आने का मौका देगा। तब शायद इसे मूल TSLint नियम के रूप में जोड़ा जा सकता है, और हो सकता है कि यह मूल भाषा में override कीवर्ड के सौंदर्य लाभ को सही ठहराने के लिए पर्याप्त स्पष्टता और प्रेरणा प्रदान करे।

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

क्या यह अधिक समझ में नहीं आता है कि प्रक्रिया को उल्टा कर दिया जाए और इसके बजाय nooverride प्रकार का संशोधक हो?

मुझे आपका सोचने का तरीका पसंद है, और मुझे लगता है कि आप जो खोज रहे हैं वह अंतिम है।

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

क्या इसके लिए पहले से कोई प्रस्ताव है? यदि नहीं, तो यह ओवरराइड करने के विकल्प के रूप में जांच के लायक हो सकता है ...

_संपादित करें:_ पता चलता है कि आप केवल पढ़ने वाले सदस्य को ओवरराइड कर सकते हैं, इसलिए यह पूरा तर्क ध्वस्त हो जाता है।

शायद private वर्ग कार्यों की अनुमति देना एक और विकल्प है?

संपादित करें: मैं सोच रहा था "इसे अंतिम रूप देने के बजाय" लेकिन मैं आधा सो रहा होगा (जाहिर है "अंतिम" का अर्थ सार्वजनिक है लेकिन ओवरराइड नहीं कर सकता), एलओएल; कोई बात नहीं।

@rjamesnw आप पहले से ही वर्ग कार्यों को सार्वजनिक, संरक्षित, निजी के रूप में परिभाषित कर सकते हैं।

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

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

मुझे लगता है कि बिना override , टाइपस्क्रिप्ट अपने उपयोगकर्ताओं को संकलन-समय सुरक्षा और टाइप-सुरक्षा के अपने [कथित] वादे पर निराश कर रहा है।
कोड विकसित हो रहा है (जैसा कि अन्य लोगों ने बताया है) "विधि को ओवरराइड करने के लिए आईडीई कमांड का उपयोग करें" तर्क टूट जाता है।
ऐसा भी लगता है कि सभी प्रमुख तुलनीय भाषाओं ने किसी न किसी रूप में override जोड़ा है।
इसे एक ब्रेकिंग परिवर्तन नहीं बनाने के लिए, यह एक tslint नियम हो सकता है (इसी तरह जावा में)।
बीटीडब्ल्यू, प्रमुख संस्करण भाषा जैसे 2.x -> 3.x के बीच परिवर्तनों को तोड़ने की अनुमति क्यों न दें। हम फंसना नहीं चाहते हैं, है ना?
अगर यह पता चलता है कि override के कुछ विवरणों में कुछ गड़बड़ है, और इसके लिए 3.x में कुछ ब्रेकिंग-चेंज-ट्वीकिंग की आवश्यकता है, तो ऐसा ही हो। मुझे लगता है कि ज्यादातर लोग विकास की गति बनाम संगतता के व्यापार को समझेंगे और उसकी सराहना करेंगे। वास्तव में override के बिना मैं टीएस को जावा या सी # से अधिक व्यावहारिक के रूप में अनुशंसा नहीं कर सकता ...

यदि लोग सख्त होना चाहते हैं, तो अनिवार्य override (एक वैकल्पिक tslint नियम हो सकता है) का कोई तरीका होना चाहिए। अनिवार्य override का मूल्य हालांकि बहुत कम है, क्योंकि गलती से सुपरक्लास से किसी विधि को ओवरराइड करने की संभावना गलती से नॉट -ओवरराइडिंग की तुलना में बहुत कम लगती है।

वास्तव में 2015 से खुला यह मुद्दा मेरे टाइपस्क्रिप्ट उत्साह और इंजीलवाद पर ठंडे पानी की एक बाल्टी है ...

यह भव्य * - माता-पिता से ओवरराइडिंग विधियों को संभालता नहीं है:

/* Put this in a helper library somewhere */ function override(container, key, other1) { var baseType = Object.getPrototypeOf(container); if(typeof baseType[key] !== 'function') { throw new Error('Method ' + key + ' of ' + container.constructor.name + ' does not override any base class method'); } }

यह भी दुखद और निराशाजनक है कि इस मुद्दे पर जीएच पर No one assigned । शायद टाइपस्क्रिप्ट कांटा के लिए समय? ;) CompileTimeSafeScript...

यह पूरा धागा एक बड़े "विश्लेषण द्वारा पक्षाघात" विरोधी पैटर्न जैसा दिखता है। क्यों न केवल "80% मामलों का मूल्य 20% काम के साथ है" और, इसे व्यवहार में आज़माएँ, और, यदि आवश्यक हो, तो इसे 3.x में ट्वीक करें?

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

तो, डेकोरेटर्स के माध्यम से संकलन समय पर टाइप-चेक करना संभव है, भले ही थोड़ी सी मदद के बिना नहीं:

export const override = <P extends Function>() => <K extends keyof P["prototype"]>(
  target: Object,
  methodName: K,
  descriptor: TypedPropertyDescriptor<P["prototype"][K]>
) => {
  // this is a no-op. The checking is all performed at compile-time, so runtime checks are not needed.
}

class Bar {
  biz (): boolean {
    return true;
  }

  qux (): string {
    return "hi";
  }
}

class Foo extends Bar {
  // this is fine
  @override<typeof Bar>()
  biz (): boolean {
    return false;
  }

  // error: type '() => number' is not assignable to type '() => boolean'
  @override<typeof Bar>()
  biz (): number {
    return 5;
  }

  // error: argument of type '"baz"' is not assignable to parameter of type '"biz" | "qux"'
  @override<typeof Bar>()
  baz (): boolean {
    return false;
  }
}

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

@alangpierce

मेरी धारणा यह है कि एक टीएसलिंट नियम यहां आगे बढ़ने का सबसे आसान रास्ता होगा।

[...]

तब शायद इसे एक कोर TSLint नियम के रूप में जोड़ा जा सकता है, और हो सकता है कि यह मूल भाषा में एक ओवरराइड कीवर्ड के सौंदर्य लाभ को सही ठहराने के लिए पर्याप्त स्पष्टता और प्रेरणा प्रदान करे।

100% सहमत। आइए पहले ही शुरू कर दें!

नमस्ते - योजना से थोड़ी देर बाद लेकिन यहाँ हमारा tslint नियम एक डेकोरेटर का उपयोग करके लागू किया गया है।

https://github.com/bet365/override-linting-rule

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

हमारे उपयोग के मामले में यह अमूल्य रहा है - हालांकि हम अभी भी इस राय के हैं कि जिम्मेदारी अंततः संकलक के साथ होनी चाहिए और इस तरह लाइनिंग नियम को स्टॉप-गैप के रूप में देखा जाना चाहिए।

धन्यवाद

मैं सहमत हूं। मैं यह भी मानता हूं कि टीएस कंपाइलर से जुड़ा एक समाधान डेकोरेटर्स और लिंट नियमों से काफी बेहतर होगा।

इस सुविधा की स्थिति क्या है? क्या इसे अभी तक एक कंपाइलर-फीचर के रूप में दोबारा देखा गया है?

तो, डेकोरेटर्स के माध्यम से संकलन समय पर टाइप-चेक करना संभव है, भले ही थोड़ी सी मदद के बिना नहीं:

कुछ सुधार:

function override< Sup >( sup : { prototype : Sup } ) {
    return <
        Field extends keyof Sup ,
        Proto extends { [ key in Field ] : Sup[ Field ] } ,
    >(
        proto : Proto ,
        field : Field ,
        descr : TypedPropertyDescriptor< Sup[ Field ] > ,
    )=> {}
}

class Foo {

    bar( a : number ) {
        return a 
    }

    bar2( a : number , b : number ) {
        return a 
    }

}

class Foo2 {

    @override( Foo )
    bar( a : number ) {
        return 1
    }

    @override( Foo )
    bar2( a : number , b : number ) {
        return 1 
    }

    xxx() { return '777' }

}

class Foo3 extends Foo2 {

    @override( Foo ) // OK
    bar( a : number ) { return 5 }

    @override( Foo ) // Error: less args than should
    bar2( a : number ) { return 5 }

    @override( Foo ) // Error: accidental override Foo2
    xxx() { return '666' }

    @override( Foo ) // Error: override of absent method
    yyy() { return 0 }

}

खेल का मैदान

ठीक है, ओवरराइड समाधान मिला जो संकलन त्रुटि को रोकता है।
नोड पठनीय धारा के साथ उदाहरण:

// Interface so you will keep typings for all Readable methods/properties that are not overriden:
// Fileds that are `Omit`-ed should be overriden (with any signature you want, it do not have to be compatible with parent class)
interface ReadableObjStream<T> extends Omit<stream.Readable, 'push' | 'read'> {}

// Use extends (TYPE as any) to avoid compilation errors and override `Omit`-ted methods
class ReadableObjStream<T> extends (stream.Readable as any) {
    constructor()  {
        super({objectMode: true}); // force object mode. You can merge it with original options
    }
    // Override `Omit`-ed methods with YOUR CUSTOM SIGNATURE (can be non-comatible with parent):
    push(myOwnNonCompatibleSignature: T): string  { /* implementation*/ };
    read(options_nonCompatibleSignature: {opts: keyof T} ): string  { /* implementation*/ }
}

let typedReadable = new ReadableObjMode<{myData: string}>();
typedReadable.push({something: 'else'}); // will throw compilation error as expected
typedReadable.pipe(...) // non overloaded methods typings supported as expected

इस समाधान का एकमात्र नुकसान super.parentMethod पर कॉल करते समय टाइपिंग की कमी है (लेकिन interface ReadableObjStream के लिए धन्यवाद, आपके पास ReadableObjStream के उदाहरण का उपयोग करते समय सभी टाइपिंग हैं।

@ निन-जिन @ बायोबॉल डेकोरेटर कंपाइल-टाइम चेकिंग में योगदान के लिए धन्यवाद।

दुर्भाग्य से यह protected सदस्यों के साथ काम नहीं करता है, केवल public के साथ।

( निन-जिन के खेल के मैदान के मेरे कांटे में त्रुटि का उदाहरण

C++ 11 में ओवरराइड स्पेसिफायर एक किलर फीचर था।
यह बहुत मदद करता है और रिफैक्टरिंग कोड की सुरक्षा करता है।
मैं निश्चित रूप से इसे बिना किसी बाधा के टीएस आधार समर्थन में रखना चाहता हूं (वोट!)

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

एक अन्य विचार:

class Obj { 

    static override<
        This extends typeof Obj,
        Over extends keyof InstanceType<This> = never,
    >(this: This, ...overs: Over[]) { 
        return this as This & (
            new(...a:any[])=> InstanceType<This> & Protect< Omit<InstanceType<This> , Over > >
        )
    }

}

class Foo extends Obj {

    bar(a: number) {
        return 0
    }

    bar2(a: number) {
        return 0
    }

    foo = 1

}

class Foo2 extends Foo.override('bar') {

    foo = 2

    bar( a : number ) {
        return 1
    }

    // Error: Class 'Foo & Protect<Pick<Foo, "bar2" | "foo">>'
    // defines instance member property 'bar2',
    // but extended class 'Foo2' defines it as instance member function.
    bar2( a : number ) {
        return 1
    }

    bar3( a : number ) {
        return 1
    }

}

declare const Protected: unique symbol

type Protect<Obj> = {
    [Field in keyof Obj]:
    Object extends () => any
    ? Obj[Field] & { [Protected]: true }
    : Obj[Field]
}

खेल का मैदान लिंक

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

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

वैसे भी, क्या मेरे लिए बच्चों में सुपर कॉल को जबरदस्ती करने का कोई और तरीका है? TSLint नियम जो छिपने से रोकता है, या ऐसा ही कुछ?

पुनश्च: मैं "कोई टिप्पणी नहीं" नीति से सहमत नहीं हूं। यह लोगों को यहां उदाहरण फेंकने से रोकता है। हो सकता है कि आप 'ओवरराइड' को लागू नहीं करेंगे, लेकिन आप कुछ और लागू करेंगे, जो उनकी समस्याओं का ख्याल रखता है ... यानी, अगर आप वास्तव में उन्हें पढ़ सकते हैं।

@GonziHere अन्य भाषाओं जैसे C# या Java में, ओवरराइडिंग का अर्थ सुपर विधि को कॉल करने की आवश्यकता नहीं है - वास्तव में ऐसा अक्सर नहीं होता है। रचनाकार विशेष हैं और सामान्य "आभासी तरीके" नहीं हैं।

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

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

@GonziHere ऐसा लगता है कि अमूर्त कार्यों के साथ अमूर्त आधार वर्ग बनाने के लिए आपको वास्तव में क्या चाहिए। शायद आप निजी _onInit और _onDestroy विधियों को बना सकते हैं जिन पर आप अधिक भरोसा कर सकते हैं, फिर संरक्षित onInit और onDestroy अमूर्त फ़ंक्शंस (या नियमित फ़ंक्शंस यदि वे हैं तो बनाएं) आवश्यक नहीं)। निजी कार्य दूसरों को बुलाएंगे, फिर सामान्य रूप से पूर्ण होंगे।

@GonziHere @rjamesnw करने के लिए सुरक्षित बात वास्तव में किसी भी तरह से लागू करना है कि onInit और onDestroy _ final_ हैं, और अंतिम विधियों को कॉल करने वाले खाली संरक्षित अमूर्त टेम्पलेट विधियों को परिभाषित करते हैं। यह गारंटी देता है कि कोई भी गलती से विधियों को ओवरराइड नहीं कर सकता है, और ऐसा करने की कोशिश कर रहा है (यह मानते हुए कि अंतिम तरीकों को लागू करने का एक तरीका था) तुरंत उपयोगकर्ताओं को सही तरीके से लागू करने के लिए इंगित करेगा जो वे चाहते हैं।

@shicks , @rjamesnw , मैं @GonziHere जैसी ही स्थिति में हूं। मैं नहीं चाहता कि बेस क्लास में अमूर्त विधियां हों क्योंकि ऐसी कार्यक्षमता है जिसे मैं उन प्रत्येक जीवन चक्र हुक के लिए निष्पादित करना चाहता हूं। समस्या यह है कि मैं नहीं चाहता कि जब कोई व्यक्ति super() पर कॉल किए बिना चाइल्ड क्लास पर ngOnInit या ngOnDestroy जोड़ता है तो उस आधार कार्यक्षमता को गलती से बदल दिया जाए। override की आवश्यकता देव के ध्यान में लाएगी कि वे विधियां बेस क्लास में मौजूद हैं और उन्हें यह चुनना चाहिए कि क्या उन्हें super() पर कॉल करने की आवश्यकता है;

जावा लिखने के मेरे अनुभव से, @Override इतना सामान्य है कि यह शोर बन जाता है। कई मामलों में, ओवरराइड की गई विधि अमूर्त या खाली होती है (जहां super() को _not_ कहा जाना चाहिए), जिससे override की उपस्थिति विशेष रूप से स्पष्ट संकेत नहीं है कि super() की आवश्यकता है।

जावा लिखने के मेरे अनुभव से, @Override इतना सामान्य है कि यह शोर बन जाता है। कई मामलों में, ओवरराइड की गई विधि अमूर्त या खाली होती है (जहां super() को _not_ कहा जाना चाहिए), जिससे override की उपस्थिति विशेष रूप से स्पष्ट संकेत नहीं है कि super() की आवश्यकता है।

इसका विषय से कोई लेना-देना नहीं है। आपने समस्या से बचने के लिए वंशानुक्रम पर रचना का उपयोग करने के लिए कहा हो सकता है।

मेरे लिए, override का सबसे उपयोगी हिस्सा रिफैक्टरिंग के दौरान त्रुटि प्राप्त करना है।
अभी बेस क्लास में किसी विधि का नाम बदलना बहुत आसान है और जो इसे ओवरराइड करते हैं उनका नाम बदलना भूल जाते हैं।
super पर कॉल करना याद रखना इतना महत्वपूर्ण नहीं है। कुछ मामलों में इसे न कहना भी सही है।

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

शुद्धता सुनिश्चित करने के लिए मैं जिस पैटर्न का उपयोग करता हूं वह Parameters और ReturnType का उपयोग करना है, जबकि बेस क्लास को बहुत स्पष्ट रूप से संदर्भित करते हुए, ऐसा कुछ:

class Base {
    public methodName(arg1: string, arg2: number): boolean {
        return false; // base behaviour, may be stub.
    }
}
class Derived extends Base {
    public methodName(...args: Parameters<Base["methodName"]>): ReturnType<Base["methodName"]> {
        const [meaningful, variableNames] = args;
        return true; // implemented behaviour here.
    }
}

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

मुझे यह भी लगता है कि इस बारे में एक गलतफहमी है कि override क्यों महत्वपूर्ण होगा, लेकिन मैं वास्तव में इन सभी मुद्दों को "क्या super() की आवश्यकता है" के साथ नहीं समझता।

@lorenzodallavecchia और इस मुद्दे के मूल लेखक ने जो कहा है, उसे प्रतिध्वनित करने के लिए, एक फ़ंक्शन को override के रूप में चिह्नित करना स्क्रू-अप से बचने के लिए एक तंत्र है जो सुपरक्लास के रिफैक्टर होने पर होता है, विशेष रूप से जब नाम और/या हस्ताक्षर का ओवरराइड फ़ंक्शन बदल जाता है या फ़ंक्शन हटा दिया जाता है।

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

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

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

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

इस मामले में एक संकलन त्रुटि प्राप्त करना, यह कहते हुए कि आपको इस विधि में override कीवर्ड जोड़ने की आवश्यकता है (यहां तक ​​​​कि कठिन भी आप वास्तव में विधि को ओवरराइड नहीं कर सकते हैं, बस इसका नाम बदल दें ताकि नई बनाई गई विधि को ओवरराइड न करें बेस क्लास), बहुत बेहतर होगा और संभावित रनटाइम बग से बचें।

जावा लिखने के मेरे अनुभव से, @Override इतना सामान्य है कि यह शोर बन जाता है।

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

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

किसी अन्य जावा डेवलपर से प्रतिक्रिया ... @override एकमात्र ऐसी विशेषता है जो मैं वास्तव में टाइपस्क्रिप्ट से गायब हूं।

मेरे पास जावा का ~15 अनुभव है और 1-2 साल या टाइपस्क्रिप्ट दोनों के साथ बहुत सहज है।

@override का ज़ेन आप एक इंटरफ़ेस से एक विधि को हटा सकते हैं और संकलन टूट जाएगा।

यह नए तरीकों के लिए टाइट बाइंडिंग के विपरीत है। यह आपको पुराने को हटाने की अनुमति देता है।

यदि आप एक इंटरफ़ेस लागू करते हैं और एक विधि जोड़ते हैं तो संकलन विफल हो जाएगा लेकिन इसका कोई विलोम नहीं है।

यदि आप कोई विधि हटाते हैं तो आप बस मृत कोड के साथ समाप्त हो जाएंगे।

(हालांकि शायद यह एक लिंटर द्वारा तय किया जा सकता है)

स्पष्ट होने के लिए, जब मैंने कहा कि @Override शोर था, तो मैं विशेष रूप से टिप्पणी के बारे में यह संकेत दे रहा था कि आपको super पर कॉल करने की आवश्यकता है। यह जो जाँच प्रदान करता है वह मूल्यवान है, लेकिन किसी भी ओवरराइड विधि के लिए, यह एक पूर्ण टॉस-अप है कि क्या इसकी आवश्यकता है या super पर कॉल करना व्यर्थ है। चूंकि ओवरराइड विधियों का इतना बड़ा अंश _ should't_, यह उस उद्देश्य के लिए अप्रभावी है।

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

मैं इस बात को लेकर थोड़ा भ्रमित हूं कि लोग final या override में से किसी एक का सुझाव दूसरे पर क्यों देते रहते हैं। निश्चित रूप से हम दोनों चाहते हैं, क्योंकि वे विभिन्न समस्याओं का समाधान करते हैं।

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

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

@ सैम-एस 4 एस हम भी परिभाषित करना चाहते हैं :-)

मुद्दे का उदाहरण ..

प्रारंभिक

class Base {}
class Entity extends Base {
    id() {
        return 'BUG-123' // busisess entity id
    }
}

बेस क्लास रिफैक्टेड

class Base {
    id() {
        return '84256635572' // storage object id
    }
}
class Entity extends Base {
    id() {
        return '12' // busisess entity id
    }
}

हमें यहां आकस्मिक अधिभार मिला।

define कीवर्ड के साथ मामला

class Base {
    define id() {
        return '84256635572' // storage object id
    }
}
class Entity extends Base {
    define id() {
        return '12' // busisess entity id
    }
}

शॉल्ड बी एरर: एक्सीडेंटल रिडिफाइन।

सज्जाकारों के साथ समाधान

@ निन-जिन define के समान नहीं है _not_ override का उपयोग कर रहा है?

@ सैम-एस 4 एस हम भी परिभाषित करना चाहते हैं :-)

ओह, मैंने यहां किसी को कीवर्ड define का उल्लेख करते नहीं देखा है - लेकिन जो आप वर्णन करते हैं, मुझे लगता है कि आपका मतलब सी # में virtual शब्द जैसा है?

(मैंने आपको उदाहरण थोड़ा भ्रमित करने वाला भी पाया, क्योंकि आपकी कक्षाएं Base और Entity संबंधित नहीं हैं। क्या आपका मतलब Entity के लिए Base का विस्तार करना था?)

मुझे लगता है कि 2 परिदृश्य हैं ...
ए) आप अपना बेस क्लास लिखते हैं, मानते हैं कि final के बिना सबकुछ ओवरराइड किया जा सकता है।
बी) आप अपना बेस क्लास लिखते हैं कि virtual के बिना सबकुछ ओवरराइड नहीं किया जा सकता है।

@ सैम-एस 4 एस इकाई निश्चित रूप से बेस बढ़ाती है। :-) मैंने अपना संदेश ठीक कर लिया है। virtual कुछ और है।
@lorenzodallavecchia कंपाइलर के लिए override का उपयोग नहीं करना $# define | override है। define का उपयोग करना केवल define है और संकलक इसे सख्ती से जांच सकता है।

@ निन-जिन आपके मॉडल में, इसका मतलब है कि override कीवर्ड का उपयोग नहीं करना अभी भी कानूनी है, है ना? उदाहरण के लिए:

class Base {
  myMethod () { ... }
}

class Overridden extends Base {
  // this would not fail because this is interpreted as define | override.
  myMethod () { ... }
}

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

@bioball हाँ, यह बहुत सारे मौजूदा कोड के साथ संगतता के लिए आवश्यक है।

@ सैम-एस 4 एस इकाई निश्चित रूप से बेस बढ़ाती है। :-) मैंने अपना संदेश ठीक कर लिया है। virtual कुछ और है।

मुझे अभी भी यकीन नहीं है कि परिभाषित करके आपका क्या मतलब है ... यह सी # में virtual की परिभाषा है:

The virtual keyword is used to modify a method, property, indexer, or event declaration and allow for it to be overridden in a derived class.

हो सकता है कि आपका मतलब इसके विपरीत हो, जहां, ओवरराइड करने के लिए फ़ंक्शन को virtual के रूप में चिह्नित करने की आवश्यकता के बजाय, आप फ़ंक्शन को define के रूप में चिह्नित कर सकते हैं, इसका मतलब है कि आपको override का उपयोग करना होगा

(क्यों define ? मैंने वह कीवर्ड किसी अन्य भाषा में नहीं देखा है)

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

class Animal {
    move(meters:number):void {
    }
}

class Snake extends Animal {
    override move(meters) {
    }
}

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

class Animal {
    move(meters:number):number {
    }
}

class Snake extends Animal {
    override move(meters, time:number) {
    }
}

मेरे यहां आने और एक टिप्पणी लिखने की प्रेरणा यह है कि हमारी कंपनी को अब आवश्यकता है कि हम ओवरराइड विधियों के लिए भी सभी प्रकार निर्दिष्ट करें, क्योंकि टाइपस्क्रिप्ट में यह कार्यक्षमता नहीं है (और हम एक लंबे प्रवास में हैं)। यह काफी कष्टप्रद है।

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

@shicks आप कह सकते हैं कि वस्तुतः किसी भी आयातित चर या वर्ग के बारे में। एक फ़ाइल पर आपको आवश्यक सभी जानकारी को डुप्लिकेट करना अमूर्तता और मॉड्यूलरिटी के उद्देश्य को हरा देता है। प्रकारों को दोहराए जाने के लिए बाध्य करना DRY सिद्धांत का उल्लंघन करता है।