Typescript: स्थिर सदस्यों के लिए बहुरूपी "यह"

मेरी नाव का आकार और आकार काफी समान है! अहो!

सुपरक्लास में फ़ैक्टरी विधि अपने उपवर्गों के नए उदाहरण लौटाती है। मेरे कोड की कार्यक्षमता काम करती है लेकिन मुझे रिटर्न प्रकार डालने की आवश्यकता है:

class Parent {
    public static deserialize(data: Object): any { ... create new instance ... }
    // Can't return a this type from statics! ^^^ :(
}

class Child extends Parent { ... }

let data = { ... };
let aChild: Child = Child.deserialize(data);
//           ^^^ Requires a cast as type cannot be inferred.

मैं आज भी इस मुद्दे में भाग गया!

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

class Parent {
    static create<T extends Parent>(): T {
        let t = new this();

        return <T>t;
    }
}

class Child extends Parent {
    field: string;
}

let b = Child.create<Child>();

क्या इस मुद्दे को बंद करने का कोई कारण है?

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

उपयोग का मामला बहुत ही बुनियादी और बेहद सामान्य है। एक साधारण फ़ैक्टरी विधि पर विचार करें:

class Animal
{
    static create(): this
    {
        return new this();
    }
}

class Bunny extends Animal
{
    hop()
    {
    }
}

Bunny.create().hop() // Type error!! Come on!!

इस बिंदु पर मैं या तो बदसूरत कास्टिंग का सहारा ले रहा हूं या प्रत्येक उत्तराधिकारी में static create() विधियों का उपयोग कर रहा हूं। यह सुविधा न होना भाषा में काफी बड़ा पूर्णता छेद जैसा लगता है।

@ पॉल-गो मुद्दा बंद नहीं हुआ है ...?

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

कंपाइलर, इंटेलिजेंस, और सबसे महत्वपूर्ण बात यह है कि बनी सभी खुश हैं।

class Animal {
    public static create<T extends Animal>(): T {
        let TClass = this.constructor.prototype;
        return <T>( new TClass() );
    }
}

class Bunny extends Animal {    
    public static create(): Bunny {
        return <Bunny>super.create();
    }

    public hop(): void {
        console.log(" Hoppp!! :) ");
    }
}

Bunny.create().hop();

         \\
          \\_ " See? I am now a happy Bunny! "
           (')   " Don't be so hostile! "
          / )=           " :P "
        o( )_

@RyanCavanaugh ओह ... किसी कारण से मैंने इसे # 5862 के साथ भ्रमित कर दिया ... युद्ध कुल्हाड़ी आक्रामकता के लिए खेद है :-)

@ थिंक 7 हां ... इसलिए "बदसूरत कास्टिंग का सहारा लेना या प्रत्येक उत्तराधिकारी में स्थैतिक निर्माण() विधियों का सहारा लेना"। यह बहुत कठिन है हालांकि जब आप एक पुस्तकालय डेवलपर होते हैं और आप वास्तव में अंतिम उपयोगकर्ताओं को उन कक्षाओं में टाइप की गई स्थिर विधियों का एक समूह लागू करने के लिए मजबूर नहीं कर सकते हैं जो वे आपसे प्राप्त करते हैं।

लॉल आपके कोड के तहत सब कुछ पूरी तरह से याद किया: डी

मेह इसके लायक था, एक बनी को आकर्षित करना था।

:+1: बनी

:खरगोश: :दिल:

+1, निश्चित रूप से इसे देखना चाहेंगे

क्या इस विषय पर कोई चर्चा अपडेट हुई है?

यह हमारे विशाल सुझाव बैकलॉग पर बना हुआ है।

जावास्क्रिप्ट पहले से ही ऐसे पैटर्न में सही ढंग से कार्य करता है। यदि TS भी अनुसरण कर सकता है जो हमें बहुत सारे बॉयलरप्लेट/अतिरिक्त कोड से बचाएगा। "मॉडल पैटर्न" एक सुंदर मानक है, मैं उम्मीद करता हूं कि टीएस काम करे क्योंकि जेएस इस पर काम करता है।

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

यह #8164 में वर्णित समस्या का एक स्पष्ट समाधान प्रदान करेगा।

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

मैं Sequelize 4.0 के लिए टाइपिंग पर काम कर रहा हूं और यह एक ऐसे दृष्टिकोण का उपयोग करता है जहां आप Model वर्ग को उप-वर्गीकृत करते हैं। उस मॉडल वर्ग में अनगिनत स्थिर विधियाँ हैं जैसे findById() आदि। जो निश्चित रूप से Model नहीं लौटाते हैं, लेकिन आपके उपवर्ग, उर्फ this स्थिर संदर्भ में:

abstract class Model {
    public static tableName: string;
    public static findById(id: number): this { // error: a this type is only available in a non-static member of a class or interface 
        const rows = db.query(`SELECT * FROM ${this.tableName} WHERE id = ?`, [id]);
        const instance = new this();
        for (const column of Object.keys(rows[0])) {
            instance[column] = rows[0][column];
        }
        return instance;        
    }
}

class User extends Model {
    public static tableName = 'users';
    public username: string;    
}

const user = User.findById(1); // user instanceof User

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

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

विश्वास नहीं हो रहा है कि यह अभी भी तय / जोड़ा नहीं गया है .....

हम इसका अच्छा उपयोग कर सकते हैं:

declare class NSObject {
    init(): this;
    static alloc(): this;
}

declare class UIButton extends NSObject {
}

let btn: UIButton = UIButton.alloc().init();

यहां एक उपयोग का मामला है जो मैं चाहता हूं कि काम किया (https://github.com/Microsoft/TypeScript/issues/9775 से माइग्रेट किया गया जिसे मैंने इसके पक्ष में बंद कर दिया)

वर्तमान में एक कंस्ट्रक्टर के पैरामीटर उनमें this प्रकार का उपयोग नहीं कर सकते हैं:

class C<T> {
    constructor(
        public transformParam: (self: this) => T // not works
    ){
    }
    public transformMethod(self: this) : T { // works
        return undefined;
    }
}

अपेक्षित: यह कंस्ट्रक्टर मापदंडों के लिए उपलब्ध होगा।

एक समस्या जिसे हल करने की कोशिश की जा रही है:

• मेरे धाराप्रवाह एपीआई को उसी कोड का पुन: उपयोग करने वाले किसी अन्य धाराप्रवाह एपीआई के आसपास या तो आधार बनाने में सक्षम हो:

class TheirFluentApi {
    totallyUnrelated(): TheirFluentApi {
        return this;
    }
}

class MyFluentApi<FluentApi> {
    constructor(
        public toNextApi: (self: this) => FluentApi // let's imagine it works
    ){
    }
    one(): FluentApi {
        return this.toNextApi(this);
    }
    another(): FluentApi {
        return this.toNextApi(this);
    }
}

// self based fluent API;
const selfBased = new MyFluentApi(this => this);
selfBased.one().another();

// foreign based fluent API:
const foreignBased = new MyFluentApi(this => new TheirFluentApi());
foreignBased.one().totallyUnrelated();

फ्यूचर-प्रूफ वर्कअराउंड:

class Foo {

    foo() { }

    static create<T extends Foo>(): Foo & T {
        return new this() as Foo & T;
    }
}

class Bar extends Foo {

    bar() {}
}

class Baz extends Bar {

    baz() {}
}

Baz.create<Baz>().foo()
Baz.create<Baz>().bar()
Baz.create<Baz>().baz()

इस तरह, जब टाइपस्क्रिप्ट स्थिर सदस्यों के लिए this समर्थन करता है, तो नया उपयोगकर्ता कोड Baz.create() के बजाय Baz.create<Baz>() होगा जबकि पुराना उपयोगकर्ता कोड ठीक काम करेगा। :मुस्कुराओ:

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

मैं कह सकता हूं कि यह कुछ भ्रम पैदा कर सकता है, एक स्थिर विधि पर this प्रकार होने से उस वर्ग को हल किया जाता है, न कि कक्षा के प्रकार (यानी: typeof )।

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

हालांकि, लोगों के अंतर्ज्ञान में मुझे लगता है कि पहली चीज जो एक स्थिर विधि पर this रिटर्न प्रकार देखते समय पॉप अप होती है वह इंस्टेंस प्रकार है ...

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

@felixfbecker यह पूरी तरह से एक दृष्टिकोण बिंदु है, इस तरह आप इसे देखना चुनते हैं।

आइए देखें कि JS में क्या होता है, इसलिए हम तर्क का अनुमान लगा सकते हैं:

class Example {
  myFunc(): this {
    return this; 
  }

  static myFuncStatic(): this {
    return this;   // this === Example
  }
}

new Example().myFunc() //  instanceof Exapmle === true
Example.myFuncStatic() // === Example

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

सारांश में:
प्रोटोटाइप (उदाहरण) के हिस्से के रूप में परिभाषित this लौटने वाली एक विधि से उदाहरण वापस आने की उम्मीद है।

उस तर्क को जारी रखते हुए, this लौटाने वाली एक विधि जिसे वर्ग प्रकार (प्रोटोटाइप) के भाग के रूप में परिभाषित किया गया है, से बंधे हुए संदर्भ को वापस करने की उम्मीद की जाती है, जो कि वर्ग प्रकार है।

फिर, कोई पूर्वाग्रह नहीं, कोई राय नहीं, साधारण तथ्य।

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

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

@felixfbecker यह एक और मुद्दा उठाता है!

यदि प्रकार this इंस्टेंस प्रकार है, तो यह स्थिर विधि के मुख्य भाग में this कीवर्ड के संदर्भ में भिन्न है। return this एक फ़ंक्शन रिटर्न प्रकार उत्पन्न करता है typeof this , जो पूरी तरह से अजीब है!

नहीं यह नहीं। जब आप एक विधि को परिभाषित करते हैं जैसे

getUser(): User {
  ...
}

आप उपयोगकर्ता _instance_ वापस प्राप्त करने की अपेक्षा करते हैं, न कि उपयोगकर्ता वर्ग (यही वह है जो typeof के लिए है)। यह हर टाइप की गई भाषा में कैसे काम करता है। टाइप सेमेन्टिक्स रनटाइम सेमेन्टिक्स से बिल्कुल अलग हैं।

क्यों न this या static कीवर्ड का उपयोग एक बच्चे वर्ग के साथ हेरफेर करने के लिए func में एक निर्माता के रूप में करें?

class Model {
  static find():this[] {
    return [new this("prop")]; // or new static(...)
  }
}

class Entity extends Model {
  constructor(public prop:string) {}
}

Entity.find().map(x => console.log(x.prop));

और अगर हम इसकी तुलना JS में एक उदाहरण से करते हैं, तो हम देखेंगे कि यह सही तरीके से क्या काम करता है:

class Model {
  static find() { 
    return [new this] 
  }
}

class Entity extends Model {
  constructor(prop) {
    this.prop = prop;
  }
}

Entity.find().map(x => console.log(x.prop))

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

@felixfbecker

इस पर विचार करो:

class Greeter {
    static getHandle(): this {
        return this;
    }
}

इस प्रकार का एनोटेशन सहज है, लेकिन गलत है यदि एक स्थिर विधि में टाइप this क्लास इंस्टेंस है। एक स्थिर विधि में कीवर्ड this में typeof this $ का एक प्रकार है!

मुझे लगता है कि this _ चाहिए_ उदाहरण प्रकार को संदर्भित करता है, न कि वर्ग प्रकार, क्योंकि हम उदाहरण प्रकार से वर्ग प्रकार का संदर्भ प्राप्त कर सकते हैं ( typeof X ) लेकिन इसके विपरीत नहीं ( instancetypeof X ?)

@xealot ठीक है, इसके बजाय $ static कीवर्ड का उपयोग क्यों न करें $ this ? लेकिन जेएस स्थिर संदर्भ में this अभी भी एक निर्माता को इंगित करता है।

@izatop हाँ, उत्पन्न जावास्क्रिप्ट काम करता है (ठीक से या अनुचित तरीके से)। हालांकि, यह जावास्क्रिप्ट के बारे में नहीं है। शिकायत यह नहीं है कि जावास्क्रिप्ट भाषा इस पैटर्न की अनुमति नहीं देती है, यह है कि टाइपस्क्रिप्ट का टाइप सिस्टम नहीं करता है।

आप इस पैटर्न के साथ टाइप सुरक्षा को बनाए नहीं रख सकते क्योंकि टाइपस्क्रिप्ट स्थिर सदस्यों पर पॉलीमॉर्फिक this प्रकारों की अनुमति नहीं देता है। इसमें static कीवर्ड और constructor के साथ परिभाषित वर्ग विधियां शामिल हैं।

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

@LPGhatguy लेकिन आपने मेरी पिछली टिप्पणी पढ़ी, है ना ?! यदि आपके पास वापसी प्रकार User के साथ कोई विधि है, तो आप return new User(); की अपेक्षा करते हैं, न कि return User; । उसी तरह this के वापसी मूल्य का मतलब स्थिर विधि में return new this(); $ होना चाहिए। गैर स्थैतिक तरीकों में यह अलग है, लेकिन यह स्पष्ट है क्योंकि this हमेशा एक वस्तु है, आप इसे तुरंत चालू नहीं कर पाएंगे। लेकिन अंत में, हम मूल रूप से सभी सहमत हैं कि typeof के कारण यह सबसे अच्छा सिंटैक्स है और TS में इस सुविधा की बहुत आवश्यकता है।

@xealot मैं समझता हूं कि टाइपस्क्रिप्ट बहुरूपी this की अनुमति नहीं देता है, फिर भी मैं आपसे पूछूंगा कि इस सुविधा को TS में क्यों नहीं जोड़ा जाए?

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

टाइपस्क्रिप्ट@2.0.0 . के साथ काम करता है

निम्न पर विचार करें ;

// IModelClass is just here to describe an instanciator
// since we can't use typeof T (unfortunately) with
// the generic type system.
interface IModelClass<T extends Model> {
  new (...a: any[]): T

  // unfortunately, we have to put here again all the typing information
  // of the static members (without static, since we are describing a class, not an instance)

  some_member: string
  create<T extends Model>(this: IModelClass<T>): T
}

class Model {

  // Here we use this with the IModel<T> to force the
  // type system to use T as our current caller.

  static some_member: string

  // When we call Dog.create() below, T is thus resolved
  // to Dog *and stays that way*
  // If typeof worked on generic types (it doesn't), we could have defined this method
  // instead as 
  // static create<T extends Model>(this: typeof T): T { ... }
  static create<T extends Model>(this: IModelClass<T>): T {
    return new this() // whatever you fancy here
  }
}

class Dog extends Model {
  bark() { }
}

class Cat extends Model {
  meow() { }
}

// Everything should be typed here, and we didn't have to redefine static methods
// in Dog nor Cat
let dog = Dog.create()
dog.bark()
let cat = Cat.create()
cat.meow()

@ceymard पैरामीटर के रूप में this क्यों दिया गया है?

यह https://github.com/Microsoft/TypeScript/issues/3694 के कारण है जिसे टाइपस्क्रिप्ट 2.0.0 के साथ भेजा गया था जो कार्यों के लिए इस पैरामीटर को परिभाषित करने की अनुमति देता है (इस प्रकार this बिना उनके शरीर में उपयोग की अनुमति देता है समस्याओं और कार्यों के गलत उपयोग को रोकने के लिए)

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

(ध्यान दें कि this टाइपस्क्रिप्ट कंपाइलर द्वारा समझा जाने वाला एक _special_ पैरामीटर है, यह फ़ंक्शन में एक और नहीं जोड़ता है)

मैंने सोचा था कि वाक्यविन्यास <this extends Whatever> जैसा कुछ था। तो यह तब भी काम करेगा जब create() में अन्य पैरामीटर हों?

बिल्कुल

मैं यह भी बताना चाहता था कि यह बिल्ड-इन प्रकारों के लिए महत्वपूर्ण है।
जब आप उदाहरण के लिए Array उपवर्ग करते हैं, तो उपवर्ग की from() विधि उपवर्ग का एक उदाहरण लौटाएगी, न कि Array ।

class Task {}
class TaskList extends Array<Task> {
  public execute() {}
}
// actually returns instance of TaskList at runtime
const tasks = TaskList.from([new Task()])
tasks.execute() // error, method execute does not exist on type Array

इस मुद्दे पर कोई अपडेट? यह फीचर टाइपस्क्रिप्ट के साथ मेरी टीम के अनुभव को काफी बढ़ा देगा।

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

मैं काउंटर तर्क के खिलाफ कुछ काउंटर तर्क उठाऊंगा।

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

और वर्तमान टाइपस्क्रिप्ट में आसान समाधान है। @ceymard पहले ही दिखा चुका है कि . और मैं उनके दृष्टिकोण को पसंद करूंगा क्योंकि यह स्थैतिक विधि के रनटाइम सिमेंटिक को पकड़ लेता है। इस कोड पर विचार करें।

class A {
  constructor() {}
  static create<T extends A>(this: {new (): T}) {} // constructor signature is exactly the same as A's
}

class B extends A {
  constructor(a: number) {
    super()
  }
}

B.create() // correctly trigger compile error here

यदि बहुरूपी यह समर्थित है, तो संकलक को class B extends A में त्रुटि की रिपोर्ट करनी चाहिए। लेकिन यह एक तोड़ने वाला बदलाव है।

@HerringtonDarkholme मुझे भ्रम नहीं दिख रहा है, वापसी प्रकार this ठीक वही है जो मैं return new this() से अपेक्षा करता हूं। संभावित रूप से हम उसके लिए self का उपयोग कर सकते हैं, लेकिन किसी अन्य कीवर्ड (आउटपुट को उत्पन्न करने के लिए उपयोग किए जाने वाले के अलावा) को पेश करना मेरे लिए अधिक भ्रमित करने वाला लगता है। हम इसे पहले से ही रिटर्न प्रकार के रूप में उपयोग करते हैं, एकमात्र (लेकिन बड़ी) समस्या यह है कि यह स्थिर सदस्यों में समर्थित नहीं है।

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

मेथड बॉडी में this this प्रकार से अलग क्यों है?
यह कोड विफल क्यों होता है? आप इसे एक नए आने वाले को कैसे समझा सकते हैं?

class A {
  static create(): this {
     return this
  }
}

जावास्क्रिप्ट का एक सुपरसेट इसे स्वीकार करने में विफल क्यों होगा?

class A {
  static create() {
    return new this()
  }
}

abstract class B extends A {}

सच है, तब हमें एक और खोजशब्द पेश करने की आवश्यकता हो सकती है। self हो सकता है, या शायद instance

@HerringtonDarkholme यहां बताया गया है कि मैं इसे एक नवागंतुक को कैसे समझाता हूं।
जब तुम करोगे

class A {
  static whatever(): B {
    return new B();
  }
}

B का रिटर्न प्रकार का अर्थ है कि आपको B का एक उदाहरण वापस करने की आवश्यकता है। यदि आप कक्षा को स्वयं वापस करना चाहते हैं, तो आपको उपयोग करने की आवश्यकता है

class B {
 static whatever(): typeof B {
   return B;
 }
}

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

class A {
  static whatever(): this {
    return new this();
  }
}

यदि आप कक्षा को स्वयं वापस करना चाहते हैं, तो आपको typeof this का उपयोग करने की आवश्यकता है:

class A {
  static whatever(): typeof this {
    return this;
  }
}

ठीक इसी तरह टीएस में पहले से ही टाइप पहले से ही काम कर रहे हैं। यदि आप किसी वर्ग के साथ टाइप करते हैं, तो TS एक उदाहरण की अपेक्षा करता है। यदि आप वर्ग प्रकार के लिए ही टाइप करना चाहते हैं, तो आपको typeof का उपयोग करने की आवश्यकता है।

तब मैं पूछूंगा कि विधि निकाय में this का समान अर्थ क्यों नहीं है। यदि this इंस्टेंस मेथड के टाइप एनोटेशन का अर्थ 'संबंधित मेथड बॉडी' में this के साथ समान है, तो यह स्टैटिक मेथड के लिए समान क्यों नहीं है?

हम एक दुविधा का सामना कर रहे हैं और तीन विकल्प हैं:

1. this बनाने का मतलब अलग-अलग संदर्भ में अलग-अलग चीजें हैं (भ्रम)
2. self या static . जैसे नए कीवर्ड का परिचय दें
3. प्रोग्रामर को अधिक अजीब प्रकार का एनोटेशन लिखने दें (कुछ उपयोगकर्ताओं को प्रभावित करें)

मैं तीसरा दृष्टिकोण पसंद करता हूं क्योंकि यह स्थैतिक विधि परिभाषा के रनटाइम सिमेंटिक को दर्शाता है।
यह साइट को परिभाषित करने के बजाय उपयोग साइट पर त्रुटियों को भी स्पॉट करता है, अर्थात, इस टिप्पणी में, त्रुटि B.create में रिपोर्ट की गई है, न कि class B extends A में। इस मामले में साइट त्रुटि का उपयोग अधिक सटीक है। (मान लें कि आप एक स्थिर विधि घोषित करते हैं जो this के संदर्भ में है और फिर एक सार उपवर्ग घोषित करें)।

और, सबसे महत्वपूर्ण बात, इसे नई सुविधा के लिए भाषा प्रस्ताव की आवश्यकता नहीं है।

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

@HerringtonDarkholme क्योंकि उदाहरण के तरीकों के मामले में, रनटाइम this एक ऑब्जेक्ट इंस्टेंस है और क्लास नहीं है, इसलिए भ्रम की कोई जगह नहीं है। यह स्पष्ट है कि प्रकार this वस्तुतः रनटाइम this है, कोई अन्य विकल्प नहीं है। जबकि स्थिर मामले में यह किसी भी वस्तु उन्मुख प्रोग्रामिंग भाषा में किसी भी अन्य वर्ग एनोटेशन की तरह व्यवहार करता है: इसे कक्षा के साथ एनोटेट करें, और आप एक उदाहरण की उम्मीद करते हैं। इसके अलावा टीएस मामले में, क्योंकि जावास्क्रिप्ट कक्षाओं में भी वस्तुएं हैं, इसे typeof एक वर्ग के साथ टाइप करें और आपको शाब्दिक वर्ग वापस मिल जाएगा।

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

ठीक है, मान लेते हैं कि कोई भी this से भ्रमित नहीं होगा। अमूर्त वर्ग असाइनमेंट के बारे में कैसे?

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

@HerringtonDarkholme आप निस्संदेह सही हैं कि this के उपयोग से भ्रम पैदा होगा। हालांकि, चूंकि this का उपयोग करने में कुछ भी गलत नहीं है, मैं कहूंगा कि यह पूरी तरह से ठीक है, खासकर जब विभिन्न विकल्पों के आपके सूक्ष्म लागत लाभ विश्लेषण को ध्यान में रखते हुए। मुझे लगता है कि this कम से कम खराब विकल्प है।

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

स्पष्ट करने के लिए, इच्छा है कि this टाइप एनोटेशन पॉलीमॉर्फिक हो जब कंस्ट्रक्टर में उपयोग किया जाता है, विशेष रूप से एक सामान्य/टेम्पलेट के रूप में। @shlomiassaf और @HerringtonDarkholme के संबंध में मेरा मानना ​​है कि static विधियों के साथ उदाहरण भ्रमित करने वाला हो सकता है और यह इस मुद्दे का इरादा नहीं है।

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

अंतर यह है कि मैं नहीं चाहता कि this एक स्थिर विधि पर तुरंत गणना की जाए, लेकिन भविष्य में एक गतिशील में।

// START LIBRARY CODE
// Constrains the constructor to one that creates things that extend from BaseModel
interface ModelConstructor<T extends BaseModel> {
    new(fac: ModelAPI<T>): T;
}

class ModelAPI<T extends BaseModel> {
    // skipping the use of a ModelConstructor in favor of typeof does not work
    // constructor(private modelType: typeof T) {}
    constructor(private modelType: ModelConstructor<T>) {}

    create() {
        return new this.modelType(this);
    }
}

class BaseModel {
    // This is where "polymorphic `this`" in static members matters. We are 
    // trying to say that the ModelAPI should create instances of whatever 
    // the *current* class is, not the BaseModel class. Much like it would 
    // at runtime.
    constructor(private fac: ModelAPI<this>) {}

    reload() {
        // `reload()` returns a new instance of type Any, incorrect
        return this.fac.create();
    }
}
// END LIBRARY CODE

// START APPLICATION CODE
// Create a custom model class with custom behavior
class Model extends BaseModel {}

// Create an instance of the model API that produces my custom type
let api = new ModelAPI<Model>(Model);  // ModalAPI should be able to infer "<Model>" from the constructor?
let modelInst = api.create();  // Returns type of Model, correct
let reset = modelInst.reload();  // Returns type of Any, incorrect
// END APPLICATION CODE

किसी के लिए भी जो सोचता है कि यह भ्रमित करने वाला है, ठीक है, यह सुपर स्ट्रेट फॉरवर्ड नहीं है, मैं सहमत हूं। हालांकि, this का उपयोग BaseModel के कंस्ट्रक्टर में वास्तव में एक स्थिर उपयोग नहीं है, यह बाद में गणना करने के लिए एक आस्थगित उपयोग है। हालाँकि, स्थिर विधियाँ (कन्स्ट्रक्टर सहित) उस तरह से काम नहीं करती हैं।

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

क्षमा करें यदि यह एक भ्रमित करने वाली टिप्पणी है, जो जल्दबाजी में लिखी गई है।

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

आपका सटीक उपयोग मामला क्या है? शायद यही 'समाधान' काफी है।

मैं इसे सफलता के साथ एक कस्टम ओआरएम लाइब्रेरी में उपयोग करता हूं
ले ज्यू। 20 अक्टूबर 2016 19:15, टॉम मारियस नोटिफिकेशन @github.com a
इक्रिट:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/5863#issuecomment -255169194,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAtAoRHc45B386xdNhuCLB8iW6i82e7Uks5q16GzgaJpZM4GsmOH
.

@ceymard और @HerringtonDarkholme को धन्यवाद।

static create<T extends A>(this: {new (): T}) { return new this(); } ने मेरे लिए चाल चली

यह पहली नजर में static create(): this { return new this(); } से अधिक अस्पष्ट है लेकिन कम से कम, यह सही है! यह स्थिर विधि के अंदर this के प्रकार को सटीक रूप से कैप्चर करता है।

मुझे उम्मीद है कि इसे किसी भी तरह से प्राथमिकता दी जा सकती है, भले ही यह सबसे ऊपर या टिप्पणी आदि न हो। सही प्रकार प्राप्त करने के लिए टाइप तर्क का उपयोग करना बहुत परेशान है, उदाहरण के लिए:

let u = User.create<User>();

जब ऐसा करना व्यावहारिक रूप से संभव हो:

let u = User.create();

और यह अनिवार्य है कि स्थैतिक कभी-कभी उदाहरण प्रकारों को संदर्भित करता है।

मेरे पास इस बारे में चर्चा के बारे में एक और विचार था कि स्थिर सदस्यों में this प्रकार वर्ग के स्थिर पक्ष या उदाहरण पक्ष का प्रकार होना चाहिए। this स्थिर पक्ष हो सकता है, यह उदाहरण के सदस्यों में क्या किया जाता है और रनटाइम व्यवहार क्या होता है, और फिर आप this.prototype के माध्यम से इंस्टेंस प्रकार प्राप्त कर सकते हैं:

abstract class Model {
  static findAll(): Promise<this.prototype[]>
}

class User extends Model {}

const users: User[] = await User.findAll();

यह जावास्क्रिप्ट में कैसे काम करता है, इसके अनुरूप होगा। this वर्ग वस्तु ही है, और उदाहरण this.prototype पर है। यह अनिवार्य रूप से मैप किए गए प्रकारों के समान मैकेनिक है, जो this['prototype'] के बराबर है।

उसी तरह आप this.constructor (मैं इस एटीएम के लिए उपयोग के मामले के बारे में नहीं सोच सकता) के माध्यम से उदाहरण के सदस्यों में स्थिर पक्ष उपलब्ध होने की कल्पना कर सकता हूं।

मैं यह भी उल्लेख करना चाहता था कि उल्लिखित वर्कअराउंड/हैक्स में से कोई भी सीक्वेलाइज में ओआरएम मॉडल टाइप करने के लिए काम नहीं करता है।

• this टाइप एनोटेशन का उपयोग कंस्ट्रक्टर में नहीं किया जा सकता है, इसलिए यह इस हस्ताक्षर के लिए काम नहीं करता है:
  ts abstract class Model { constructor(values: Partial<this.prototype>) }
• प्रकार को सामान्य वर्ग तर्क के रूप में पास करना स्थिर तरीकों के लिए काम नहीं करता है, क्योंकि स्थिर सदस्य सामान्य पैरामीटर का संदर्भ नहीं दे सकते हैं
• एक सामान्य विधि तर्क के रूप में प्रकार पास करना विधियों के लिए काम करता है, लेकिन स्थिर गुणों के लिए काम नहीं करता है, जैसे:
  ts abstract class Model { static attributes: { [K in keyof this.prototype]: { type: DataType, field: string, unique: boolean, primaryKey: boolean, autoIncrement: boolean } }; }

इस अनुरोध के लिए +1। मेरा ओआरएम बहुत साफ होगा।

आशा है कि हम जल्द ही स्वच्छ समाधान देखेंगे

इस बीच, समाधान की पेशकश करने वाले सभी को धन्यवाद!

क्‍या हम इस पर और आगे बढ़ सकते हैं क्‍योंकि अब कोई चर्चा नहीं है?

आप इसे कहाँ ले जाना चाहेंगे? यह अभी भी एक तरीका है जिसमें टाइपस्क्रिप्ट जावास्क्रिप्ट को स्पष्ट रूप से मॉडल नहीं कर सकता है जहां तक ​​​​मुझे पता है और इसे न करने के अलावा किसी अन्य काम को नहीं देखा है।

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

@pleerock @xealot Solutions ऊपर प्रस्तावित किए गए हैं:

export type StaticThis<T> = { new (): T };

export class Base {
    static create<T extends Base>(this: StaticThis<T>) {
        const that = new this();
        return that;
    }
    baseMethod() { }
}

export class Derived extends Base {
    derivedMethod() { }
}

// works
Base.create().baseMethod();
Derived.create().baseMethod();
// works too
Derived.create().derivedMethod();
// does not work (normal)
Base.create().derivedMethod();

मैं इसका व्यापक रूप से उपयोग कर रहा हूं। आधार वर्गों में स्थिर विधियों की घोषणाएं थोड़ी भारी हैं लेकिन स्थिर विधियों के अंदर this के प्रकार पर विकृति से बचने के लिए भुगतान करने की कीमत है।

@प्लेरॉक

मेरे पास एक इन-हाउस ओआरएम है जो बिना किसी समस्या के this: पैटर्न का व्यापक रूप से उपयोग करता है।

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

शायद इस प्रश्न और संदर्भ के लिए समाधान के साथ एक स्टैक ओवरफ्लो धागा हो सकता है?

@bjouhier @ceymard मैंने समझाया कि इस थ्रेड में सभी वर्कअराउंड Sequelize के लिए काम क्यों नहीं करते हैं: https://github.com/Microsoft/TypeScript/issues/5863#issuecomment -269463313

और यह केवल ओआरएम के बारे में नहीं है, बल्कि मानक पुस्तकालय भी है: https://github.com/Microsoft/TypeScript/issues/5863#issuecomment -244550725

@felixfbecker ने कंस्ट्रक्टर के उपयोग के मामले के बारे में कुछ पोस्ट किया और इसे हटा दिया (मुझे एहसास हुआ कि TS पोस्ट करने के बाद हर उपवर्ग में कंस्ट्रक्टरों को अनिवार्य नहीं करता है)।

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

@bjouhier इसका मतलब यह होगा कि आपको मूल रूप से प्रत्येक मॉडल उपवर्ग में हर एक विधि को फिर से शुरू करना होगा। देखिए Sequelize में कितने हैं: http://docs.sequelizejs.com/class/lib/model.js~Model.html

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

और मेरी समझ यह है कि टाइपप्रति जावास्क्रिप्ट का विस्तार होना चाहिए।

@felixfbecker

इसका मतलब यह होगा कि आपको मूल रूप से प्रत्येक मॉडल उपवर्ग में हर एक विधि को फिर से घोषित करना होगा।

क्यों? ऐसा मेरा अनुभव कतई नहीं है। क्या आप कोड नमूने के साथ समस्या का वर्णन कर सकते हैं?

@bjouhier मैंने इस धागे में अपनी टिप्पणियों में कोड नमूने के साथ गहराई से समस्या का वर्णन किया है, एक शुरुआत के लिए https://github.com/Microsoft/TypeScript/issues/5863#issuecomment -222348054

लेकिन ऊपर मेरा create उदाहरण देखें । create विधि एक स्थिर विधि है। इसे फिर से घोषित नहीं किया गया है और फिर भी इसे उपवर्ग में ठीक से टाइप किया गया है। फिर Model के तरीकों को फिर से परिभाषित करने की आवश्यकता क्यों होगी?

@felixfbecker आपका _एक प्रारंभ_ उदाहरण के लिए:

export type StaticThis<T> = { new (): T };

abstract class Model {
    public static tableName: string;
    public static findById<T extends Model>(this: StaticThis<T>, id: number): T {
        const instance = new this();
        // details omitted
        return instance;        
    }
}

class User extends Model {
    public static tableName = 'users';
    public username: string;
}

const user = User.findById(1); 
console.log(user.username);

@bjouhier ठीक है, तो ऐसा लगता है कि this: { new (): T } एनोटेशन वास्तव में टाइप अनुमान कार्य करता है। जो मुझे आश्चर्यचकित करता है कि यह संकलक का उपयोग करने वाला डिफ़ॉल्ट प्रकार क्यों नहीं है।
निश्चित रूप से वर्कअराउंड कंस्ट्रक्टर के लिए काम नहीं करता है, क्योंकि उनके पास this पैरामीटर नहीं हो सकता है।

हां, यह कंस्ट्रक्टरों के लिए काम नहीं करता है, लेकिन आप एक स्थिर create विधि जोड़कर, एक छोटे से एपीआई परिवर्तन के साथ समस्या को हल कर सकते हैं।

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

यदि this का अर्थ स्थिर विधि के अंदर { new (): T } है, तो this स्थिर विधि के अंदर this के लिए सही प्रकार नहीं होगा। उदाहरण के लिए new this() की अनुमति नहीं होगी। निरंतरता के लिए, this कंस्ट्रक्टर फ़ंक्शन का प्रकार होना चाहिए, न कि क्लास इंस्टेंस का प्रकार।

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

यदि आप बेस क्लास के स्थिर गुणों का उपयोग करना चाहते हैं तो आप इसका उपयोग कर सकते हैं

public static findById<T extends Model>(this: (new () => T) & typeof Model, id: number): T {...}

लेकिन आपके पास शायद कंस्ट्रक्टर के बारे में एक वैध बिंदु है। मुझे एक कठिन कारण नहीं दिख रहा है कि संकलक को निम्नलिखित को अस्वीकार क्यों करना चाहिए:

constructor(values: Partial<this>) {}

मैं @xealot से सहमत हूं कि यहां दर्द है। कितना अच्छा होता अगर हम लिख पाते

static findById(id: number): instanceof this { ... }

के बजाए

static findById<T extends Model>(this: (new () => T), id: number): T { ... }

लेकिन हमें टाइपिंग सिस्टम ( instanceof ?) में एक नए ऑपरेटर की जरूरत है। निम्नलिखित अमान्य है:

static findById(id: number): this { ... }

TS 2.4 ने मेरे लिए इन वर्कअराउंड को तोड़ा:
https://travis-ci.org/types/sequelize/builds/247636686

@sandersn @felixfbecker मुझे लगता है कि यह एक वैध बग है। हालाँकि, मैं इसे न्यूनतम फैशन में पुन: पेश नहीं कर सकता। कॉलबैक पैरामीटर contravariant है।

// Hooks
User.afterFind((users: User[], options: FindOptions) => {
  console.log('found');
});

कोई मौका यह किसी बिंदु पर तय किया जाएगा?

मैं आज भी इसमें भाग गया। मूल रूप से मैं इस तरह एक सिंगलटन बेस क्लास बनाना चाहता था:

abstract class Singleton<T> {
  private static _instance?: T

  public static function getInstance (): T {
    return this._instance || (this._instance = new T())
  }
}

उपयोग कुछ ऐसा होगा:

class Foo extends Singleton<Foo> {
  bar () {
    console.log('baz!')
  }
}

Foo.getInstance().bar() // baz!

मैंने इसके लगभग 10 रूपों की कोशिश की, ऊपर वर्णित StaticThis संस्करण और कई अन्य के साथ। अंत में केवल एक ही संस्करण है जो संकलित भी करेगा, लेकिन फिर getInstance() का परिणाम केवल Object के रूप में लिया गया था।

मुझे ऐसा लगता है कि इन के रूप में निर्माण के साथ काम करने की आवश्यकता से कहीं अधिक कठिन है।

निम्नलिखित कार्य:

class Singleton {
    private static _instance?: Singleton;

    static getInstance<T extends Singleton>(this: { new(): T }) {
      const constr = this as any as typeof Singleton; // hack
      return (constr._instance || (constr._instance = new this())) as T;
    }
  }

  class Foo extends Singleton {
    foo () { console.log('foo!'); }
  }

  class Bar extends Singleton {
    bar () { console.log('bar!');}
  }

  Foo.getInstance().foo();
  Bar.getInstance().bar();

this as any as typeof Singleton भाग बदसूरत है लेकिन यह इंगित करता है कि हम टाइप सिस्टम को बेवकूफ बना रहे हैं क्योंकि _instance को व्युत्पन्न वर्ग के निर्माता पर संग्रहीत किया जाना चाहिए।

आम तौर पर, बेस क्लास को आपके ढांचे में दफनाया जाएगा, इसलिए यदि इसका कार्यान्वयन थोड़ा बदसूरत है तो इससे ज्यादा नुकसान नहीं होता है। व्युत्पन्न कक्षाओं में स्वच्छ कोड क्या मायने रखता है।

मैं 2.8 नाइटलीज़ में उम्मीद कर रहा था कि मैं ऐसा कुछ कर सकूं:

static findById(id: number): InstanceType<this> { ... }

दुर्भाग्य से ऐसी कोई किस्मत नहीं :(

@bjouhier कोड उदाहरण एक आकर्षण की तरह काम करते हैं। लेकिन IntelliSense स्वत: पूर्ण तोड़ें।

प्रतिक्रिया 16.3.0 जारी की गई थी और नई getDerivedStateFromProps विधि को ठीक से टाइप करना असंभव लगता है, यह देखते हुए कि एक स्थिर विधि वर्ग प्रकार के मापदंडों को संदर्भित नहीं कर सकती है:

(सरलीकृत उदाहरण)

class Component<P, S> {

    static getDerivedStateFromProps?<K extends keyof S>(nextProps: P, prevState: S): Pick<S, K> | null

    props: P
    state: S
}

क्या कोई उपाय है? (मैं "टाइपिंग पी और एस को पीपी और एसएस के रूप में नहीं गिनता और आशा करता हूं कि डेवलपर्स इन दो प्रकार के परिवारों को ठीक से मेल खाएंगे" एक के रूप में: पी)

पीआर: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/24577

@cncolder मैंने इंटेलिजेंस को भी तोड़ते हुए देखा है। मेरा मानना ​​​​है कि इसकी शुरुआत टाइपस्क्रिप्ट 2.7 से हुई थी।

एक चीज जो मैं यहां नहीं देखता, सिंगलटन उदाहरण पर विस्तार कर रहा हूं - सिंगलटन/मल्टीटन वर्ग को संरक्षित कन्स्ट्रक्टर बनाने के लिए यह एक सामान्य पैटर्न होगा - और इसे बढ़ाया नहीं जा सकता है यदि प्रकार { new(): T } है एक सार्वजनिक निर्माता को लागू करता है - this टर्म या यहां प्रदान किया गया अन्य समाधान ( instanceof this , typeof this आदि) को उस समस्या का समाधान करना चाहिए। कंस्ट्रक्टर में एक त्रुटि फेंकने के साथ यह निश्चित रूप से संभव है यदि सिंगलटन ने इसके निर्माण आदि का अनुरोध नहीं किया है, लेकिन यह टाइपिंग त्रुटियों के उद्देश्य को हरा देता है - एक रनटाइम समाधान के लिए ...

class Singleton {

  private static _instance?: Singleton;

  public static getInstance<T extends Singleton> ( this: { new(): T } ): T {
    const ctor: typeof Singleton = this as any; // hack
    return (ctor._instance || (ctor._instance = new this())) as T;
  }

  protected constructor ( ) { return; } 
}

class A extends Singleton {
  protected constructor ( ) {
    super();
  }
}

A.getInstance() // fails because constructor is not public

मुझे नहीं पता कि आपको getInstance() के साथ TS में सिंगलटन की आवश्यकता क्यों होगी, आप केवल एक वस्तु को शाब्दिक परिभाषित कर सकते हैं। या यदि आप पूरी तरह से कक्षाओं (निजी सदस्यों के लिए) का उपयोग करना चाहते हैं, तो केवल क्लास इंस्टेंस निर्यात करें, न कि क्लास, या क्लास एक्सप्रेशन ( export new class ... ) का उपयोग करें।

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

this -> { new(): T } & typeof Multiton | Function

class Multiton {
  private static _instances?: { [key: string]: any };

  public static getInstance<T extends Multiton> (
    this: { new(): T } & typeof Multiton | Function, key: string
  ): T {
    const instances: { [key: string]: T } =
      (this as typeof Multiton)._instances ||
     ((this as typeof Multiton)._instances = { });

    return (instances[key] ||
      (instances[key] = new (this as typeof Multiton)() as T)
    );
  }

  protected constructor ( ) { return; }
}

class A extends Multiton {
  public getA ( ): void { return; }
}
A.getInstance("some-key").getA();
assert(A.getInstance("some-key") === A.getInstance("some-key"))
new A(); // type error, protected constructor

मेरे पास कुंजी को स्टोर करने के लिए कुछ कोड भी है, इसलिए यह सृजन पर बाल वर्ग में पहुंच योग्य है, लेकिन मैंने इसे सादगी के लिए हटा दिया है ...

नमस्ते। मुझे ऐसी समस्या का सामना करना पड़ रहा है जिसके लिए कन्स्ट्रक्टर के लिए पॉलिमॉर्फिक "यह" की आवश्यकता है। इस टिप्पणी के समान।

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

मैं एक कंस्ट्रक्टर पसंद करता हूं जो गुणों को आरंभ करने के लिए किसी वस्तु को स्वीकार करता है। उदाहरण के लिए:

class Vehicle {
  // many properties here
  // ...

  constructor(value: Partial<Vehicle>) {
      Object.assign(this, value)
  }
}

let vehicle = new Vehicle({
  // <-- IntelliSense works here
})

फिर, मैं कक्षा का विस्तार करना चाहता हूं। उदाहरण के लिए:

class Car extends Vehicle {
  // more properties here
  // ...
}

let car = new Car({
  // <-- I can't infer Car's properties here
})

यह बहुत अच्छा होगा यदि कंस्ट्रक्टर पर भी this प्रकार का उपयोग किया जा सकता है।

class Vehicle {
  // ...
  constructor(value: Partial<this>) {
      // ...

इसलिए, IntelliSense अतिरिक्त बॉयलरप्लेट के बिना चाइल्ड क्लास के गुणों का अनुमान लगा सकता है: उदाहरण के लिए, कंस्ट्रक्टर को फिर से परिभाषित करना। कक्षा को प्रारंभ करने के लिए स्थिर विधि का उपयोग करने से यह अधिक प्राकृतिक दिखाई देगा।

let car = new Car({
  // <-- Car's properties will be able to be inferred if Partial<this> is allowed
})

आपके विचार के लिए बहुत - बहुत धन्यवाद।

मुझे खुशी है कि मुझे यह धागा मिला। मुझे ईमानदारी से लगता है कि यह एक बहुत ही गंभीर मुद्दा है और इसे 3.0 तक ले जाने के लिए बहुत निराश था।

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

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

सभी के लिए मेरी सिफारिश है कि यह स्वीकार करें कि स्क्वीगली दोषपूर्ण हैं और जब संभव हो तो //@ts-ignore because my code works as expected का उपयोग करें।

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

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

export class Sequence<T> {
  static from(...values) {
    // … returns Sequence<T>
  };
}

export class Peekable<T> extends Sequence<T> {
  // no augmentations needed in actual class body
}

/// AMBIENT /// Usually keep those at the bottom of my files

export declare namespace Peekable {
  export function from<T>(... values: T[]): Peekable<T>;
}

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

सुरक्षित सरणी

/**
 * Represents an Automation SAFEARRAY
 */
declare class SafeArray<T = any> {
    private constructor();
    private SafeArray_typekey: SafeArray<T>;
}

वर्डेट

/**
 * Automation date (VT_DATE)
 */
declare class VarDate {
    private constructor();
    private VarDate_typekey: VarDate;
}

आज कुछ देर चर्चा हुई। प्रमुख बिंदु:

• क्या this उदाहरण पक्ष या स्थिर पक्ष को संदर्भित करता है?
  
  
  
  • निश्चित रूप से स्थिर पक्ष। उदाहरण पक्ष को InstanceTypeOf के माध्यम से संदर्भित किया जा सकता है लेकिन विपरीत सत्य नहीं है। यह समरूपता भी बनाए रखता है कि हस्ताक्षर में $# this 2$#$ का शरीर में this के समान प्रकार है।
  
  
• सुदृढ़ता की समस्या
  
  
  
  • इस बात की कोई गारंटी नहीं है कि एक व्युत्पन्न वर्ग कंस्ट्रक्टर पैरामीटर सूची का उसके बेस क्लास कंस्ट्रक्टर पैरामीटर सूची से कोई संबंध है
  
  
  • इस संबंध में कक्षाएं अक्सर स्थैतिक-पक्ष प्रतिस्थापन को तोड़ती हैं
  
  
  • गैर-निर्माण-पक्ष प्रतिस्थापन योग्यता लागू की जाती है और यह आमतौर पर वही है जो लोग वैसे भी रुचि रखते हैं
  
  
  • हम पहले ही static new this() के गलत आह्वान की अनुमति देते हैं
  
  
  • संभावित रूप से कोई भी बाहर से स्थिर this के निर्माण हस्ताक्षर पक्ष की परवाह नहीं करता है?
  
  

मौजूदा उपाय:

class Foo {
    static boo<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();

विशेष रूप से, यह केवल तभी काम करता है जब Bar का निर्माण हस्ताक्षर Foo के लिए ठीक से प्रतिस्थापन योग्य हो

@RyanCavanaugh मैं एक स्पष्टीकरण के साथ आने की कोशिश कर रहा हूं जहां this का मूल्य आपके उदाहरण static boo<T extends typeof Foo>(this: T): InstanceType<T> से आता है, लेकिन मुझे यह नहीं मिला। यह सुनिश्चित करने के लिए कि मैं जेनरिक पर सब कुछ फिर से पढ़ता हूं, लेकिन फिर भी - नहीं। अगर मैं उदाहरण के लिए this को clazz से बदल देता हूं, तो यह अब और काम नहीं करेगा और कंपाइलर "अपेक्षित 1 तर्कों के साथ शिकायत करता है, लेकिन 0 मिला।" तो वहाँ कुछ जादू चल रहा है। क्या आप समझाएँगे? या मुझे दस्तावेज़ीकरण में सही दिशा में इंगित करें?

संपादित करें:
साथ ही, यह extends typeof Foo और केवल extends Foo क्यों नहीं है?

@creynders this एक विशेष नकली पैरामीटर है जिसे फ़ंक्शन के संदर्भ के लिए टाइप किया जा सकता है। दस्तावेज़ ।

जेनेरिक शामिल होने पर InstanceType<T> का उपयोग करना काम नहीं करता है।

मेरा उपयोग मामला कुछ इस तरह दिखता है:

const _data = Symbol('data');

class ModelBase<T> {
    [_data]: Readonly<T>;

    protected constructor(data: T) {
        this[_data] = Object.freeze(data);
    }


    static create<T, V extends typeof ModelBase>(this: V, data : T): InstanceType<V> {
        return new this(data);
    }
}

interface IUserData {
    id: number;
}

class User extends ModelBase<IUserData> {}

User.create({ id: 5 });

टाइपस्क्रिप्ट खेल का मैदान लिंक

@mastermatt ओह वाह, दस्तावेज़ों के माध्यम से पढ़ते समय इसे पूरी तरह से नहीं उठाया ... धन्यवाद

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

उदाहरण:

class Foo {
    static boo<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }

    boo<T extends typeof Foo>(this: InstanceType<T>): InstanceType<T> {
      return (this.constructor as T).boo();
    }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();
// c: Foo
let c = b.boo();

अगर मुझे इस आखिरी मुद्दे के लिए कोई समाधान मिल सकता है तो मैं कुछ आधिकारिक आने तक सेट कर दूंगा।

उस उदाहरण के साथ भी ध्यान दें, यदि उपवर्ग किसी भी स्थिर विधि को ओवरराइड करने का प्रयास करता है और फिर super पर कॉल करता है, तो यह भी परेशान हो जाता है ... इन दो मुद्दों के अलावा, कामकाज ठीक काम कर रहा है। हालाँकि, वे दो मुद्दे हमारे कोड के लिए अवरुद्ध हैं।

IIRC ऐसा इसलिए है क्योंकि यह टाइप सिस्टम को थोड़ा झुकाए बिना टाइपस्क्रिप्ट में व्यक्त नहीं किया जा सकता है। के रूप में ; this.constructor बिल्कुल भी गारंटी नहीं है कि आप क्या सोचते हैं या ऐसा ही कुछ है।

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

मेरा सामान्य तर्क यह है कि मैं चाहता हूं कि एपीआई बाकी कोड के लिए यथासंभव सरल हो, भले ही कभी-कभी इसका मतलब थोड़ा धोखा देना हो।

अगर किसी के पास कुछ और मजबूत है, तो मुझे अच्छा लगेगा

class Foo {
  static boo<T extends typeof Foo>(this: T): InstanceType<T> {
      return (new this()) as InstanceType<T>;
  }

  boo(): this {
    // @ts-ignore : wow this is ugly 
    return (this.constructor).boo();
  }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();
// c: Bar !
let c = b.boo();

आप इंटरफ़ेस मार्ग पर भी जा सकते हैं और ऐसा कुछ कर सकते हैं;

interface FooMaker<T> {
  new(...a: any[]): T
  boo(): T
}


class Foo {
  static boo<T extends typeof Foo>(this: T): InstanceType<T> {
      return (new this()) as InstanceType<T>;
  }

  boo(): this {
    return (this.constructor as FooMaker<this>).boo();
  }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();
// c: Bar !
let c = b.boo();

यह भी धोखा है, लेकिन शायद थोड़ा और नियंत्रित? मैं वास्तव में नहीं कह सकता।

तो स्थिर "बू" विधि में पहला, this तर्क विशेष रूप से माना जाता है, नियमित तर्क के रूप में नहीं? इसका वर्णन करने वाले दस्तावेज़ों के लिए कोई लिंक?

class Foo {
    static boo<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();

मुझे वही (कम से कम समान) समस्या हो रही है।
मैं JSDoc (टाइपस्क्रिप्ट नहीं) के साथ वेनिला जावास्क्रिप्ट का उपयोग कर रहा हूं, इसलिए मैं इस थ्रेड में प्रस्तावित जेनरिक के इर्द-गिर्द घूमने वाले वर्कअराउंड का उपयोग/कार्यान्वयन नहीं कर सकता, लेकिन रूट समान प्रतीत होता है।
मैंने इस मुद्दे को खोला है: #28880

इस मुद्दे को सचमुच 3 साल हो चुके हैं।
क्या किसी को उपयुक्त कामकाज मिला जो मेरे लिए काम कर सके?

तीन साल

@RyanCavanaugh का काम स्थिर तरीकों के लिए बहुत अच्छा है, लेकिन एक स्थिर एक्सेसर के बारे में क्या?

class Factory<T> {
  get(): T { ... }
}

class Base {
  static factory<T extends Base>(this: Constructor<T>): Factory<T> {
    //
  }

  // what about a getter?
  static get factory<** no generics allowed for accessors **> ...
}

तीन साल

ठीक है, आप तारीखों को घटाने में आधे कुशल हैं। लेकिन क्या आप कोई समाधान पेश कर सकते हैं? ;)

@RyanCavanaugh यह एक समस्या है जब हम जनरेटर में this मान का उपयोग निम्नानुसार करते हैं:

class C {
  constructor(f: (this: this) => void) {
  }
}
new C(function* () {
  this;
  yield;
});

जब हम जनरेटर बनाते हैं, तो हम this मान का उपयोग करने के लिए तीर फ़ंक्शन का उपयोग नहीं कर सकते। तो अब हमें उपवर्गों में स्पष्ट रूप से this प्रकार घोषित करना होगा। एक वास्तविक मामला इस प्रकार है:

      class Component extends Coroutine<void> implements El {
        constructor() {
          super(function* (this: Component) {
            while (true) {
              yield;
            }
          }, { size: Infinity });
        }
        private readonly dom = Shadow.section({
          style: HTML.style(`ul { width: 100px; }`),
          content: HTML.ul([
            HTML.li(`item`)
          ] as const),
        });
        public readonly element = this.dom.element;
        public get children() {
          return this.dom.children.content.children;
        }
        public set children(children) {
          this.dom.children.content.children = children;
        }
      }

https://github.com/falsandtru/typed-dom/blob/v0.0.134/test/integration/package.ts#L469

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

सबसे साफ नहीं, लेकिन एक स्थिर विधि से बाल वर्ग तक पहुँचने के लिए उपयोगी हो सकता है।

class Base {
    static foo<T extends typeof Base>() {
        let ctr = Object.create(this.prototype as InstanceType<T>).constructor;
        // ...
    }
}

class C extends Base {
}

C.foo();

हालाँकि मुझे यकीन नहीं है कि मुझे वर्तमान में जिस समस्या का सामना करना पड़ रहा है, वह इसके कारण है, लेकिन इस मुद्दे की एक संक्षिप्त नज़र के बाद, ऐसा लगता है कि शायद ऐसा ही है। कृपया सुधार करें यदि ऐसा नहीं है।

तो मेरे पास विरासत से संबंधित निम्नलिखित 2 वर्ग हैं।

export class Target {
  public static create<T extends Target = Target>(that: Partial<T>): T {
    const obj: T = Object.create(this.prototype);
    this.mapObject(obj, that);
    return obj;
  }
  public static mapObject<T extends Target = Target>(obj: T, that: Partial<T>) {
    // works with "strictNullChecks": false
    obj.prop1 = that.prop1;
    obj.prop2 = that.prop2;
  }

  public prop1!: string;
  constructor(public prop2: string) {}
}

export class SubTarget extends Target {
  public subProp!: string;
}

इसके बाद, मैं SubTarget वर्ग में एक mapObject विधि इस प्रकार जोड़ता हूं।

  public static mapObject(obj: SubTarget, that: Partial<SubTarget>) {
    super.mapObject(obj, that);
    obj.subProp = that.subProp;
  }

हालांकि मुझे उम्मीद थी कि यह काम करेगा, मुझे निम्न त्रुटि मिलती है।

Class static side 'typeof SubTarget' incorrectly extends base class static side 'typeof Target'.
  Types of property 'mapObject' are incompatible.
    Type '(obj: SubTarget, that: Partial<SubTarget>) => void' is not assignable to type '<T extends Target>(obj: T, that: Partial<T>) => void'.
      Types of parameters 'obj' and 'obj' are incompatible.
        Type 'T' is not assignable to type 'SubTarget'.
          Property 'subProp' is missing in type 'Target' but required in type 'SubTarget'.

क्या यह त्रुटि इस समस्या के कारण उत्पन्न हुई है? अन्यथा, एक स्पष्टीकरण वास्तव में बहुत अच्छा होगा।

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

वास्तविक वर्ग के नए उदाहरण लौटाने वाले स्थैतिक तरीकों को एनोटेट करने के समाधान की तलाश में यहां आया था।

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

लेकिन गंभीरता से, यह अभी तक कोर टाइपस्क्रिप्ट का हिस्सा कैसे नहीं है? यह काफी सामान्य परिदृश्य है।

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

यह काम नहीं करता है:

export class Base {
  static getEntitySchema<T extends typeof Base>(
    this: T,
  ): InstanceType<T> {
  }
}

export class Extension extends Base {
  static member: string = '';
  static getEntitySchema<T extends typeof Extension>(
    this: T,
  ): InstanceType<T> {
  }
}

Type 'typeof Base' is missing the following properties from type 'typeof Extension ': member.

लेकिन क्या इसकी अनुमति नहीं दी जानी चाहिए क्योंकि विस्तार आधार बढ़ाता है?

ध्यान दें यह काम करता है:

export class Extension extends Base {
  static member: string = '';
  static getEntitySchema<T extends typeof Base>(
    this: T,
  ): InstanceType<T> {
  }
}

लेकिन फिर आप इसका उपयोग नहीं कर सकते। इसके अंदर सदस्य।

तो मैं @ntucker पोस्ट से अनुमान लगा रहा हूं कि वर्कअराउंड केवल एक स्तर गहरा काम करता है जब तक कि विस्तारित वर्ग बेस क्लास से बिल्कुल मेल नहीं खाता?

नमस्कार! संरक्षित रचनाकारों के बारे में क्या?

class A {
  static create<T extends A>(
    this: {new(): T}
  ) {
    return new this();
  }

  protected constructor() {}
}

class B extends A {} 

B.create(); // Error ts(2684)

यदि कंस्ट्रक्टर सार्वजनिक है - यह ठीक है, लेकिन यदि नहीं, तो यह एक त्रुटि का कारण बनता है:

The 'this' context of type 'typeof B' is not assignable to method's 'this' of type '(new () => B) & typeof A'.
  Type 'typeof B' is not assignable to type 'new () => B'.
    Cannot assign a 'protected' constructor type to a 'public' constructor type.

खेल का मैदान - http://tiny.cc/r74c9y

क्या इसके लिए कोई आशा है? बस एक बार फिर इस जरूरत पर ठोकर खाई :F

@ntuker Duuuuudee, आपने कर दिखाया !!! मेरे लिए मुख्य अहसास था स्थैतिक निर्माण विधि को सामान्य बनाना, this परम घोषित करना, और फिर अंत में InstanceType<U> कास्ट करना।

खेल का मैदान

ऊपर से ^

class Base<T> {
  public static create<U extends typeof Base>(
    this: U
  ) {
    return new this() as InstanceType<U>
  }
}

class Derived extends Base<Derived> {}
const d: Derived = Derived.create() // works 😄 

यह मेरे उपयोग के मामले को पूरी तरह से संतुष्ट करता है, और ऐसा लगता है कि टीएस 3.5.1 के रूप में यह इस धागे में अधिकांश पीपीएल को भी संतुष्ट करता है (स्थिर प्रोप theAnswer के साथ-साथ विस्तार के तीसरे स्तर की खोज के लिए खेल का मैदान देखें)

हॉट टेक: मुझे लगता है कि यह अब काम करता है और इसे बंद किया जा सकता है?

@jonjaques बीटीडब्ल्यू आप कभी भी टी का उपयोग नहीं करते हैं। इसके अलावा, यह उस समस्या को हल नहीं करता है जिसे मैंने रेखांकित किया है जो ओवरराइडिंग विधियां हैं।

मुझे लगता है कि उल्लिखित समाधान लगभग 4 साल पहले ही सुझाया गया था ... और फिर भी यह ऐसा कुछ नहीं है जो इस मुद्दे को हल करता है।

मैंने यह देखने के लिए एक स्टैक ओवरफ्लो खोला कि क्या कोई अन्य कामकाज था जिसके बारे में कोई जानता हो और किसी के पास समस्या का अच्छा सारांश था जो मैं अनुभव कर रहा हूं:

"इस पैरामीटर सहित विधि पैरामीटर के रूप में उपयोग किए जाने वाले जेनरिक, विरोधाभासी प्रतीत होते हैं, लेकिन वास्तव में आप हमेशा चाहते हैं कि इस पैरामीटर को सहसंयोजक (या यहां तक ​​​​कि द्विभाजित) के रूप में माना जाए।"

तो ऐसा लगता है कि यह वास्तव में कुछ ऐसा है जो टाइपस्क्रिप्ट में ही टूटा हुआ है और इसे ठीक किया जाना चाहिए ('यह' सहसंयोजक या द्विचर होना चाहिए)।

संपादित करें: इस टिप्पणी का एक बेहतर तरीका है।

मेरे पास जोड़ने के लिए बहुत कुछ नहीं है, लेकिन इसने मेरे लिए https://github.com/microsoft/TypeScript/issues/5863#issuecomment -437217433 से अच्छा काम किया

class Foo {
    static create<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }
}

class Bar extends Foo { }

// typeof b is Bar.
const b = Bar.create()

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

एक अन्य उपयोग मामला गैर वर्गों पर कस्टम प्रकार गार्ड सदस्य कार्य है:

type Baz = {
    type: "baz"
}
type Bar = {
     type: "bar"
}
type Foo = (Baz|Bar)&{
    isBar: () => this is Bar 
}

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

interface IAutomobileOptions {
  make: string
}

interface ITruckOptions extends IAutomobileOptions {
  bedLength: number
}

export class Automobile<O extends IAutomobileOptions> {
  constructor(public options: O) {}

  static create<T extends typeof Automobile, O extends IAutomobileOptions>(
    this: T,
    options: O
  ): InstanceType<T> {
    return new this(options) as InstanceType<T>
  }
}

export class Truck<O extends ITruckOptions> extends Automobile<O> {
  constructor(truckOptions: O) {
    super(truckOptions)
  }
}

const car = Automobile.create({ make: 'Audi' })
const truck = Truck.create({ make: 'Ford', bedLength: 7 }) // TS Error on Truck

यहाँ त्रुटि है:

The 'this' context of type 'typeof Truck' is not assignable to method's 'this' of type 'typeof Automobile'.
  Types of parameters 'truckOptions' and 'options' are incompatible.
    Type 'O' is not assignable to type 'ITruckOptions'.
      Property 'bedLength' is missing in type 'IAutomobileOptions' but required in type 'ITruckOptions'.ts(2684)

यह मेरे लिए समझ में आता है, क्योंकि create विधि में Automobile वर्ग में ITruckOptions से O का कोई संदर्भ नहीं है, लेकिन मैं सोच रहा हूं कि क्या कोई है उस मुद्दे के लिए समाधान?

आम तौर पर कन्स्ट्रक्टर के लिए मेरे विस्तारित वर्ग 'विकल्प बेस क्लास' विकल्प इंटरफ़ेस का विस्तार करेंगे, इसलिए मुझे पता है कि वे हमेशा बेस क्लास के पैरामीटर शामिल करेंगे, लेकिन यह सुनिश्चित करने का एक विश्वसनीय तरीका नहीं है कि वे विस्तार के लिए पैरामीटर शामिल करें कक्षा।

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

@ जैक-बैरी यह काम करता है:

interface IAutomobileOptions {
  make: string
}

interface ITruckOptions extends IAutomobileOptions {
  bedLength: number
}

export class Automobile<O extends IAutomobileOptions> {
  constructor(public options: O) { }

  static create<T extends Automobile<O>, O extends IAutomobileOptions>(
    this: { new(options: O): T; },
    options: O
  ): T {
    return new this(options)
  }
}

export class Truck<O extends ITruckOptions> extends Automobile<O> {
  constructor(truckOptions: O) {
    super(truckOptions)
  }
}

const car = Automobile.create({ make: 'Audi' });
const truck = Truck.create({ make: 'Ford', bedLength: 7 });

हालांकि, यह अभी भी आदर्श नहीं है क्योंकि रचनाकार सार्वजनिक हैं इसलिए केवल new Automobile({ make: "Audi" }) करना संभव है।

@elderapo मुझे लगता है कि मुझे वह मिलता है जो मुझे चाहिए - उदाहरण निश्चित रूप से विकसित है, लेकिन मैं देखता हूं कि _Generics_ की मेरी समझ की कमी मुझे थोड़ी सी कहां है। इसे क्लीयर करने के लिए शुक्रिया!

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

// Interface to ensure attributes that exist on all descendants
interface IBaseClassAttributes {
  foo: string
}

// Type to provide inferred instance of class
type ThisClass<
  Attributes extends IBaseClassAttributes,
  InstanceType extends BaseClass<Attributes>
> = {
  new (attributes: Attributes): InstanceType
}

// Constructor uses generic A to assign attributes on instances
class BaseClass<A extends IBaseClassAttributes = IBaseClassAttributes> {
  constructor(public attributes: A) {}

  // this returns an instance of type ThisClass
  public static create<A extends IBaseClassAttributes, T extends BaseClass<A>>(
    this: ThisClass<A, T>,
    attributes: A
  ): T {
    // Perform db creation actions here
    return new this(attributes)
  }

  // Note that read function is a place where typechecking could fail you if db
  //   return value does not match
  public static read<A extends IBaseClassAttributes>(id: string): A | null {
    // Perform db retrieval here assign to variable
    const dbReturnValue = {} as A | null
    return dbReturnValue
  }
}

interface IExtendingClassAttributes extends IBaseClassAttributes {
  bar: number
}

// Extend the BaseClass with the extending attributes interface
class ExtendingClass extends BaseClass<IExtendingClassAttributes> {}

// BaseClass
const bc: BaseClass = BaseClass.create({ foo: '' })
const bca: IBaseClassAttributes = BaseClass.read('a') as IBaseClassAttributes
console.log(bc.attributes.foo)
console.log(bca.foo)

// ExtendingClass
// Note that the create and read methods do not have to be overriden,
//  but typechecking still works as expected here
const ec: ExtendingClass = ExtendingClass.create({ foo: 'bar', bar: 0 })
const eca: IExtendingClassAttributes = ExtendingClass.read(
  'a'
) as IExtendingClassAttributes
console.log(ec.attributes.foo)
console.log(ec.attributes.bar)
console.log(eca.foo)
console.log(eca.bar)

आप इस पैटर्न को शेष सीआरयूडी क्रियाओं तक आसानी से बढ़ा सकते हैं।

@ जैक-बैरी के उदाहरण में, मैं कक्षा का एक उदाहरण वापस करने के लिए read फ़ंक्शन प्राप्त करने का प्रयास करता हूं। मुझे निम्नलिखित काम करने की उम्मीद थी:

class BaseClass<A extends IBaseClassAttributes = IBaseClassAttributes> {

  public static read<A extends IBaseClassAttributes, T extends BaseClass<A>>(
    this: ThisClass<A, T>,
    id: string,
  ): T | null {
    // Perform db retrieval here assign to variable
    const dbReturnValue = {} as A | null
    if (dbReturnValue === null) {
      return null;
    }
    return this.create(dbReturnValue);
  }
}

लेकिन इसके बजाय त्रुटि प्राप्त करें Property 'create' does not exist on type 'ThisClass<A, T>'. क्या किसी के पास इससे निपटने का तरीका होगा?

@everhardt चूंकि create विधि static है, इसलिए इसे class के this पर कॉल करने की आवश्यकता होगी, उदाहरण के लिए नहीं। उस ने कहा कि मेरे पास वास्तव में मेरे सिर के ऊपर से एक अच्छा कामकाज नहीं है कि कैसे class फ़ंक्शन को गतिशील रूप से एक्सेस किया जाए जो अभी भी वांछित प्रकार की जाँच प्रदान करता है।

मैं जो निकटतम प्राप्त कर सकता हूं वह विशेष रूप से सुरुचिपूर्ण नहीं है, और मौजूदा type से BaseClass.create का उपयोग करने में सक्षम नहीं है, इसलिए वे आसानी से सिंक से बाहर हो सकते हैं:

return (this.constructor as unknown as { create: (attributes: A) => T }).create(dbReturnValue)

मैंने _ नहीं _ इसका परीक्षण किया है।

@ जैक-बैरी तो आपको this.constructor.create is not a function मिलता है।

यह समझ में आता है: टाइपस्क्रिप्ट उदाहरण के रूप में this की व्याख्या कर रहा है, लेकिन अंतिम जावास्क्रिप्ट पार्सर के लिए, this वर्ग है क्योंकि फ़ंक्शन स्थिर है।

शायद जैक-बैरी के उदाहरण का सबसे प्रेरित विस्तार नहीं है, लेकिन इस खेल का मैदान लिंक पर आप देख सकते हैं कि मैंने इसे कैसे हल किया।

निचोड़:

• प्रकार ThisClass को सभी स्थिर गुणों और विधियों का वर्णन करना चाहिए जो बेसक्लास (स्थिर और उदाहरण दोनों) के तरीकों को पॉलिमॉर्फिक 'इस' के साथ उपयोग करना चाहते हैं।
• इंस्टेंस विधि में स्थिर संपत्ति या विधि का उपयोग करते समय, (this.constructor as ThisClass<A, this>) . का उपयोग करें

यह दोहरा काम है, क्योंकि आपको वर्ग और ThisClass दोनों प्रकार के स्थिर तरीकों और गुणों को परिभाषित करना है, लेकिन मेरे लिए यह काम करता है।

संपादित करें: खेल का मैदान लिंक तय किया

PHP ने इस मुद्दे को बहुत पहले ठीक किया था। स्वयं। स्थिर। यह।

नमस्कार, यह 2020 है, जिसमें _this_ समस्या है। मैं

class Animal { 
  static create() { 
    return new this()
  }
}
class Bunny extends Animal {}
const bugs = Bunny.create() // const bugs: Animal

मुझे उम्मीद है कि bugs Bunny का उदाहरण होगा।

वर्तमान कामकाज क्या है? मैंने इस मुद्दे में सब कुछ करने की कोशिश की है, कुछ भी ठीक नहीं लगता है।

अद्यतन : यह काम किया, this तर्क परिभाषा से चूक गया।

class Animal { 
  static create<T extends typeof Animal>(this: T): InstanceType<T> { 
    return (new this()) as InstanceType<T>
  }
}
class Bunny extends Animal {}
const bugs = Bunny.create() // const bugs: Bunny

इसके साथ मुद्दा यह है कि गेटर्स और सेटर्स में टाइप पैरामीटर नहीं हो सकते हैं।

यह भी वर्बोज़ है।

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

class BaseClass {
  static InnerClass = class BaseInnerClass {};

  static createInnerClass<T extends typeof BaseClass>(this: T) {
    return new this.InnerClass() as InstanceType<T['InnerClass']>;
  }
}

class SubClass extends BaseClass {
  static InnerClass = class SubInnerClass extends BaseClass.InnerClass {};
}

const baseInnerClass = BaseClass.createInnerClass(); // => BaseInnerClass

const subInnerClass = SubClass.createInnerClass(); // => SubInnerClass

ऐसा लगता है कि यह ठीक काम करता है, लेकिन मेरी राय में createInnerClass() की टाइपिंग बहुत अधिक क्रियात्मक है, और मेरे कोडबेस में मेरे पास बहुत कुछ होगा। क्या किसी के पास इस कोड को सरल बनाने के बारे में कोई विचार है?

उस दृष्टिकोण के साथ मुद्दा यह है कि यह स्थिर गेटर्स और सेटर्स के साथ काम नहीं करता है।

स्थिर गुणों के लिए self. को लागू करने के बारे में कैसे? मुझे 4 साल पहले यह समस्या थी, और मैं उसी समस्या के साथ उसी धागे पर वापस आ रहा हूं।

@sudomaxime यह इस मुद्दे के दायरे से बाहर है और तब तक टाइपस्क्रिप्ट डिज़ाइन लक्ष्यों के विपरीत चलता है जब तक कि ECMAScript मूल रूप से self. को कक्षाओं में this.constructor. के उपनाम के रूप में समर्थन नहीं करता है, जिसकी संभावना नहीं है यह देखते हुए कि self एक सामान्य चर नाम है।

@ अब्दुल्ला-कासिम का समाधान वर्णित के रूप में काम करता प्रतीत होता है, लेकिन मैं इसे सामान्य वर्गों के साथ काम करने में सक्षम नहीं हूं:

class Animal<A> {
  public thing?: A;

  static create<T extends typeof Animal>(this: T): InstanceType<T> {
    return new this() as InstanceType<T>;
  }
}

type Foo = {};
class Bunny extends Animal<Foo> {}

const bunny = Bunny.create(); // typeof bunny is Animal<unknown>
bunny.thing;                  // unknown :(

   __     __
  /_/|   |\_\  
   |U|___|U|
   |       |
   | ,   , |
  (  = Y =  )
   |   `  |
  /|       |\
  \| |   | |/
 (_|_|___|_|_)
   '"'   '"'

मैं इस पर किसी भी विचार की सराहना करता हूं कि क्या यह संभव है क्योंकि मैंने इसके साथ थोड़ा सा बिना किसी भाग्य के साथ छेड़छाड़ की है।

@stevehanson क्या यह आपके लिए काम करेगा?

class Animal<A> {
  public thing?: A;

  static create<T>(this: new () => T): T {
    return new this() as T;
  }
}

type Foo = {asd: 123};
class Bunny extends Animal<Foo> {
    public hiya: string = "hi there"
}

const bunny = Bunny.create()


bunny.thing

const test = bunny.thing?.asd

const hiya = bunny.hiya

टाइपस्क्रिप्ट खेल के मैदान पर इसका परीक्षण किया।

इस लिंक से प्रेरित:
https://selleo.com/til/posts/gll9bsvjcj-generic-with-class-as-argument-and-returning-instance

और मुझे यकीन नहीं है कि यह कैसे इंगित करने में कामयाब रहा कि टी वर्ग ही है । संपादित करें: आह, मुझे याद आया, यह टी को इंगित करने में कामयाब रहा क्योंकि मूक this पैरामीटर हमेशा कक्षा को ही पास कर देगा।

@ अब्दुल्ला-कासिम यह काम किया! वाह धन्यवाद! मेरे विशिष्ट मामले के लिए, मेरा निर्माता एक तर्क लेता है, इसलिए यह मेरे लिए ऐसा दिखता था, अगर यह किसी और की मदद करता है:

  static define<C, T, F = any, I = any>(
    this: new (generator: GeneratorFn<T, F, I>) => C,
    generator: GeneratorFn<T, F, I>,
  ): C {
    return new this(generator);
  }

यहां कुछ समाधान स्थिर गेटर्स के लिए काम नहीं करते हैं क्योंकि मैं इसमें कोई तर्क नहीं दे सकता:

नीचे दिए गए उदाहरण को देखते हुए मैं default स्थिर गेटर को मूल वर्ग में कैसे स्थानांतरित कर सकता हूं?

class Letters {
  alpha: string = 'alpha'
  beta?: string
  gamma?: string
  static get default () {
    return new this()
  }
}

const x = Letters.default.alpha;

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

संभावित रूप से संबंधित: मुझे @ abdullah-kasim के उदाहरण में अमूर्तता की एक और परत जोड़ने में कठिनाई हो रही है। अनिवार्य रूप से, मैं Animal को एक इंटरफ़ेस में बदलने में सक्षम होना चाहता हूं, और Bunny को अपने स्वयं के स्थिर create() $ को परिभाषित करने की अनुमति देना चाहता हूं।

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

(नीचे दिए गए उदाहरण के प्रकार बिल्कुल सही नहीं हैं - उम्मीद है कि यह काफी स्पष्ट है कि मैं क्या हासिल करने की कोशिश कर रहा हूं)

interface ParseableDoc {
    parse<T>(this: new () => T, serialized:string): T|null;
}

interface Doc {
    getMetadata():string;
}

// EXPECT: no error!
const MarkdownDoc:ParseableDoc = class implements Doc {
    constructor(private meta:string){ };
    getMetadata():string { return this.meta; };

    static parse(serialized:string):typeof MarkdownDoc | null {
        // do something specific
        return null;
    }
}

// EXPECT: type error, since class defines no static parse()
const MissingParseDoc:ParseableDoc = class implements Doc {
    constructor(private meta:string){ };
    getMetadata():string { return this.meta; };
}

// EXPECT: type error, since parse() should return a MismatchedDoc
const MismatchDoc: ParseableDoc = class implements Doc {
    constructor(private meta:string){ };
    getMetadata():string { return this.meta; };

    static parse(serialized:string):typeof MismatchDoc | null {
        // do something specific
        return null;
    }
}

(मुझे लगता है) मैं कुछ इस तरह लिखने में सक्षम होना चाहूंगा:

interface ParseableDoc {
    getMetadata():string;
    static parse<T extends ParseableDoc>(this: new () => T, serialized:string): T|null;
}

class MarkdownDoc implements ParseableDoc {
    getMetadata():string { return ""; }

    static parse(serialized:string):MarkdownDoc|null {
        // do something specific
        return null;
    }
}

कोई विचार है कि यहां भी कामकाज संभव है या नहीं?

संपादित करें: संभावित समाधान

StackOverflow पर एक और उपयोग का मामला
जेनेरिक लुकअप टेबल क्लास डिजाइन करने के लिए।

// Generic part
abstract class Table<T extends Model> {
    instances: Map<number, T> = new Map();
}
abstract class Model {
    constructor(
        public readonly id: number,
        public table: Table<this>  // Error
    ) { 
        table.instances.set(id, this);
    }
}

// Example: a table of Person objects
class Person extends Model {
    constructor(
        id: number,
        table: Table<this>,  // Error
        public name: string
    ) {
        super(id, table);
    }
}
class PersonTable extends Table<Person> {}

const personTable = new PersonTable();
const person = new Person(0, personTable, 'John Doe');

// Note: the idea of using `this` as generic type argument is to guarantee
// that other models cannot be added to a table of persons, e.g. this would fail:
//     class SomeModel extends Model { prop = 0; }
//     const someModel = new SomeModel(1, person.table);
//                                        ^^^^^^^^^^^^

@Think7 ने 29 मई 2016 को टिप्पणी की
विश्वास नहीं हो रहा है कि यह अभी भी तय / जोड़ा नहीं गया है .....

हा हा
2020 यहाँ है!

यह हास्यास्पद और पागल है। यह 2020 है। 4 साल बाद, इसे ठीक क्यों नहीं किया गया?

क्यों न कुछ इस तरह लागू किया जाए

class Model {
  static create(){
     return new static()
  }
  //or
  static create(): this {
     return new this()
  }
}

class User extends Model {
  //...
}

let user = new User.create() // type === User