स्टेटिक इंटरफ़ेस विधियां आम तौर पर समझ में नहीं आती हैं, #13462 देखें

जब तक हम इस पर और प्रतिक्रिया नहीं सुन लेते, तब तक इस पर रोक लगाते रहें।

इस पर विचार करते समय हमारे मन में एक प्रमुख प्रश्न था: abstract static पद्धति को कॉल करने की अनुमति किसे है? संभवतः आप सीधे AbstractParentClass.getSomeClassDependentValue आह्वान नहीं कर सकते। लेकिन क्या आप AbstractParentClass प्रकार की अभिव्यक्ति पर विधि का आह्वान कर सकते हैं? यदि हां, तो इसकी अनुमति क्यों दी जानी चाहिए? यदि नहीं, तो सुविधा का क्या उपयोग है?

स्टेटिक इंटरफ़ेस विधियां आम तौर पर समझ में नहीं आती हैं, #13462 देखें

#13462 की चर्चा में मैंने यह नहीं देखा कि static इंटरफ़ेस के तरीके बेहूदा क्यों हैं। मैंने केवल यह देखा कि उनकी कार्यक्षमता को अन्य माध्यमों से लागू किया जा सकता है (जो साबित करता है कि वे संवेदनहीन नहीं हैं)।

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

इसलिए मुझे कोई तार्किक कारण नहीं दिखता कि class में static विधि क्यों हो सकती है और interface क्यों नहीं है।

यदि हम इस दृष्टिकोण का पालन करें कि भाषा में पहले से लागू की जा सकने वाली हर चीज को वाक्य रचना और अन्य चीजों के किसी भी सुधार की आवश्यकता नहीं है (अर्थात्, यह तर्क #13462 की चर्चा में मुख्य बिंदुओं में से एक था), तो इसके द्वारा निर्देशित दृष्टिकोण से, हम यह तय कर सकते हैं कि while चक्र निरर्थक है क्योंकि इसे for और if एक साथ उपयोग करके कार्यान्वित किया जा सकता है। लेकिन हम while को खत्म नहीं करने जा रहे हैं।

इस पर विचार करते समय हमारे मन में एक प्रमुख प्रश्न था: abstract static पद्धति को कॉल करने की अनुमति किसे है? संभवतः आप सीधे AbstractParentClass.getSomeClassDependentValue आह्वान नहीं कर सकते। लेकिन क्या आप AbstractParentClass प्रकार की अभिव्यक्ति पर विधि का आह्वान कर सकते हैं? यदि हां, तो इसकी अनुमति क्यों दी जानी चाहिए? यदि नहीं, तो सुविधा का क्या उपयोग है?

अच्छा प्रश्न। चूंकि आप इस मुद्दे पर विचार कर रहे थे, क्या आप इस बारे में अपने विचार साझा कर सकते हैं?

यह केवल मेरे दिमाग में आता है कि कंपाइलर स्तर पर AbstractParentClass.getSomeClassDependentValue की सीधी कॉल का मामला ट्रैक नहीं किया जाएगा (क्योंकि इसे ट्रैक नहीं किया जा सकता है), और जेएस रनटाइम त्रुटि होगी। लेकिन मुझे यकीन नहीं है कि यह टाइपस्क्रिप्ट विचारधारा के अनुरूप है या नहीं।

मैंने केवल यह देखा कि उनकी कार्यक्षमता को अन्य माध्यमों से लागू किया जा सकता है (जो साबित करता है कि वे संवेदनहीन नहीं हैं)।

सिर्फ इसलिए कि कुछ लागू करने योग्य है, इसका मतलब यह नहीं है कि यह समझ में आता है। मैं

abstract class Serializable {  
    abstract serialize (): Object;  
    abstract static deserialize (Object): Serializable;  
}  

मैं Serializable के उपवर्गों में स्थैतिक deserialize विधि के कार्यान्वयन को बाध्य करना चाहता हूँ।
क्या इस तरह के व्यवहार को लागू करने के लिए कोई समाधान है?

इस पर नवीनतम क्या है? मैंने बस एक अमूर्त वर्ग की एक अमूर्त स्थैतिक संपत्ति लिखने की कोशिश की और जब इसकी अनुमति नहीं थी तो वास्तव में आश्चर्यचकित हुआ।

क्या @patryk-zielinski93 ने कहा। PHP में कुछ वर्षों की परियोजनाओं से आ रहा है कि हम टीएस में कनवर्ट करते हैं, हम इंटरफेस में स्थिर तरीके चाहते हैं।

एक बहुत ही सामान्य उपयोग के मामले में यह मदद करेगा रिएक्ट घटक, जो स्थिर गुणों वाले वर्ग हैं जैसे कि displayName , propTypes , और defaultProps ।

इस सीमा के कारण, रिएक्ट के लिए टाइपिंग में वर्तमान में दो प्रकार शामिल हैं: एक Component वर्ग, और ComponentClass इंटरफ़ेस जिसमें कंस्ट्रक्टर फ़ंक्शन और स्थिर गुण शामिल हैं।

एक प्रतिक्रिया घटक को उसके सभी स्थिर गुणों के साथ पूरी तरह से टाइप करने के लिए, एक के पास दोनों प्रकार के दो उपयोग होते हैं।

उदाहरण बिना ComponentClass : स्थिर गुणों को अनदेखा किया जाता है

import React, { Component, ComponentClass } from 'react';

type Props = { name: string };

{
  class ReactComponent extends Component<Props, any> {
    // expected error, but got none: displayName should be a string
    static displayName = 1
    // expected error, but got none: defaultProps.name should be a string
    static defaultProps = { name: 1 }
  };
}

उदाहरण के साथ ComponentClass : स्थैतिक गुणों की जाँच की जाती है

{
  // error: displayName should be a string
  // error: defaultProps.name should be a string
  const ReactComponent: ComponentClass<Props> = class extends Component<Props, any> {
    static displayName = 1
    static defaultProps = { name: 1 }
  };
}

मुझे संदेह है कि कई लोग वर्तमान में ComponentClass का उपयोग नहीं कर रहे हैं, इस बात से अनजान हैं कि उनके स्थिर गुणों की जांच नहीं की जा रही है।

संबंधित समस्या: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/16967

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

abstract class Model {
    abstract static fromString(value: string): Model
}

class Animal extends Model {
    constructor(public name: string, public weight: number) {}

    static fromString(value: string): Animal {
        return new Animal(...JSON.parse(value))
    }
}

@roboslone

class Animal {
    static fromString(value: string): Animal {
        return new Animal();
    }
}

function useModel<T>(model: { fromString(value: string): T }): T {
    return model.fromString("");
}

useModel(Animal); // Works!

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

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

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

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

एक और सरल उपयोग मामला: (आदर्श तरीका, जो काम नहीं करता है)

import {map} from 'lodash';

export abstract class BaseListModel {
  abstract static get instance_type();

  items: any[];

  constructor(items?: any[]) {
    this.items = map(items, (item) => { return new this.constructor.instance_type(item) });
  }

  get length() { return this.items.length; }
}

export class QuestionList extends BaseListModel {
  static get instance_type() { return Question }
}

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

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

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

class Action {
  constructor(public type='') {}
}

class AddAppleAction extends Action {
  static create(apple: Apple) {
    return new this(apple);
  }
  constructor(public apple: Apple) {
    super('add/apple');
  }
}

class AddPearAction extends Action {
  static create(pear: Pear) {
    return new this(pear);
  }

  constructor(public pear: Pear) {
    super('add/pear');
  }
}

const ActionCreators = {
  addApple: AddAppleAction
  addPear: AddPearAction
};

const getActionCreators = <T extends Action>(map: { [key: string]: T }) => {
  return Object.entries(map).reduce((creators, [key, ActionClass]) => ({
    ...creators,
    // To have this function run properly,
    // I need to guarantee that each ActionClass (subclass of Action) has a static create method defined.
    // This is where I want to use abstract class or interface to enforce this logic.
    // I have some work around to achieve this by using interface and class decorator, but it feels tricky and buggy. A native support for abstract class method would be really helpful here.
    [key]: ActionClass.create.bind(ActionClass)
  }), {});
};

आशा है कि यह मेरी आवश्यकताओं की व्याख्या कर सकता है। धन्यवाद।

वर्कअराउंड की तलाश में किसी के लिए, आप इस डेकोरेटर का उपयोग कर सकते हैं:

class myClass {
    public classProp: string;
}

interface myConstructor {
    new(): myClass;

    public readonly staticProp: string;
}

function StaticImplements <T>() {
    return (constructor: T) => { };
}

<strong i="7">@StaticImplements</strong> <myConstructor>()
class myClass implements myClass {}

const getActionCreators = <T extends Action>(map: { [key: string]: {new () => T, create() : T}}) => {

चूंकि हम एक प्रकार पैरामीटर के माध्यम से कॉल कर रहे हैं, वास्तविक आधार वर्ग इसकी काल्पनिक abstract static फ़ैक्टरी विधि के साथ कभी भी शामिल नहीं होगा। उपवर्गों के प्रकार संरचनात्मक रूप से संबंधित होते हैं जब प्रकार पैरामीटर को तत्काल किया जाता है।

मैं इस चर्चा में जो नहीं देख रहा हूं वह ऐसे मामले हैं जहां कुछ संश्लेषित प्रकार के विपरीत आधार वर्ग के प्रकार के माध्यम से कार्यान्वयन लागू किया जाता है।

यह विचार करना भी प्रासंगिक है कि, सी # जैसी भाषाओं के विपरीत, जहां abstract सदस्य वास्तव में व्युत्पन्न कक्षाओं में उनके कार्यान्वयन द्वारा _ओवरराइडेड_ हैं, जावास्क्रिप्ट सदस्य कार्यान्वयन, उदाहरण या अन्यथा, कभी भी विरासत में मिली संख्याओं को ओवरराइड नहीं करते हैं, बल्कि _shadow_ उन्हें।

उपयोगकर्ता के दृष्टिकोण से मेरा 5 सेंट यहाँ है:

इंटरफेस मामले के लिए, इसे _static_ संशोधक की अनुमति दी जानी चाहिए

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

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

मेरी राय में यह गलत और बाधक लगता है।

क्या कोई तकनीकी पृष्ठभूमि है जो इस भाषा की विशेषता को लागू करना कठिन या असंभव बना रही है?

चियर्स

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

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

कक्षाओं के उदाहरणों पर, स्थिर विधियाँ उदाहरण पर मौजूद नहीं होती हैं।

क्या आप इसे विस्तार में बताने में सक्षम हैं? यह सी # नहीं है

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

कि हमें मिल गया है और यही हम बदलना चाहते हैं।

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

मैं उस पर पूरी तरह सहमत हूं। Json इंटरफ़ेस उदाहरण देखें

हाय @kitsonk , कृपया आप इस पर और विस्तार कर सकते हैं:

कक्षाओं में दो इंटरफेस हैं, दो कार्यान्वयन अनुबंध हैं, और इससे दूर नहीं हो रहा है।

मुझे वह हिस्सा समझ में नहीं आया।

तार्किक रूप से, इंटरफेस किसी वस्तु की सार्वजनिक सतह हैं। एक इंटरफ़ेस किसी वस्तु की सार्वजनिक सतह का वर्णन करता है। इसका मतलब है कि इसमें कुछ भी नहीं है जो वहां नहीं है।

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

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

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

fetchData(account: SalesRepresentativeInterface): Observable<Array<AccountModel>> {
    // Method Body
}

उस विधि निकाय में, मैं वास्तव में account विधियों का उपयोग कर सकता हूं। मैं जो करना चाहता हूं वह SalesRepresentativeInterface से स्थिर विधियों का उपयोग करने में सक्षम होना है जो कि account में मुझे प्राप्त होने वाली कक्षा में लागू होने के लिए पहले से ही लागू किया गया था। हो सकता है कि मैं इस सुविधा का उपयोग करने के बारे में एक बहुत ही सरल या पूरी तरह से गलत विचार कर रहा हूं।

मुझे लगता है कि static संशोधक की अनुमति देने से मुझे कुछ ऐसा करने की अनुमति मिलेगी: SalesRepresentativeInterface.staticMethodCall()

क्या मै गलत हु ?

चियर्स

@davidmpaz : आपका वाक्यविन्यास बिल्कुल सही नहीं है, लेकिन करीब है। यहां एक उदाहरण उपयोग पैटर्न है:

interface JSONSerializable {
  static fromJSON(json: any): JSONSerializable;
  toJSON(): any;
}

function makeInstance<T extends JSONSerializable>(cls: typeof T): T {
  return cls.fromJSON({});
}

class ImplementsJSONSerializable implements JSONSerializable {
  constructor(private json: any) {
  }
  static fromJSON(json: any): ImplementsJSONSerializable {
    return new ImplementsJSONSerializable(json);
  }
  toJSON(): any {
    return this.json;
  }
}

// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializable);

दुर्भाग्य से, इसके लिए काम करने के लिए, हमें टाइपस्क्रिप्ट से दो विशेषताओं की आवश्यकता है: (1) इंटरफेस में स्थिर विधियाँ और अमूर्त स्थैतिक विधियाँ; (2) जेनेरिक कक्षाओं के साथ एक प्रकार के संकेत के रूप में typeof का उपयोग करने की क्षमता।

@davidmpaz

मुझे वह हिस्सा समझ में नहीं आया।

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

interface Foo {
  bar(): void;
}

interface FooConstructor {
  new (): Foo;
  prototype: Foo;
  baz(): void;
}

declare const Foo: FooConstructor;

const foo = new Foo();
foo.bar();  // instance method
Foo.baz(); // static method

@jimmykane

क्या आप इसे विस्तार में बताने में सक्षम हैं? यह सी # नहीं है

class Foo {
    bar() {}
    static baz() {}
}

const foo = new Foo();

foo.bar();
Foo.baz();

Foo के उदाहरणों पर कोई .baz() Foo नहीं है। .baz() केवल कंस्ट्रक्टर पर मौजूद है।

एक प्रकार के परिप्रेक्ष्य से, आप इन दो इंटरफेस को संदर्भित/निकाल सकते हैं। Foo सार्वजनिक इंस्टेंस इंटरफ़ेस को संदर्भित करता है और typeof Foo सार्वजनिक कन्स्ट्रक्टर इंटरफ़ेस को संदर्भित करता है (जिसमें स्थिर विधियां शामिल होंगी)।

@kitsonk के स्पष्टीकरण का अनुसरण करने के लिए, आप जो चाहते हैं उसे प्राप्त करने के लिए ऊपर दिए गए उदाहरण को फिर से लिखा गया है:

interface JSONSerializable <T>{
    fromJSON(json: any): T;
}

function makeInstance<T>(cls: JSONSerializable<T>): T {
    return cls.fromJSON({});
}

class ImplementsJSONSerializable {
    constructor (private json: any) {
    }
    static fromJSON(json: any): ImplementsJSONSerializable {
        return new ImplementsJSONSerializable(json);
    }
    toJSON(): any {
        return this.json;
    }
}

// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializable); 

यहां ध्यान दें कि:

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

@mhegazy : आपको JSONSerializable इंटरफ़ेस में मेरी toJSON कॉल को हटाना होगा। हालांकि मेरा सरल उदाहरण फ़ंक्शन makeInstance केवल fromJSON पर कॉल करता है, किसी ऑब्जेक्ट को तुरंत चालू करना चाहते हैं, फिर इसका उपयोग करना बहुत आम है। आपने makeInstance द्वारा लौटाए गए पर कॉल करने की मेरी क्षमता को हटा दिया है, क्योंकि मैं वास्तव में नहीं जानता कि T makeInstance के अंदर क्या है (विशेष रूप से प्रासंगिक यदि makeInstance एक उदाहरण बनाने के लिए आंतरिक रूप से उपयोग की जाने वाली एक वर्ग विधि है, फिर इसका उपयोग करें)। बेशक मैं यह कर सकता था:

interface JSONSerializer {
  toJSON(): any;
}

interface JSONSerializable <T extends JSONSerializer> {
  fromJSON(json: any): T;
}

function makeInstance<T extends JSONSerializer>(cls: JSONSerializable<T>): T {
  return cls.fromJSON({});
}

class ImplementsJSONSerializer implements JSONSerializer {
  constructor (private json: any) {
  }
  static fromJSON(json: any): ImplementsJSONSerializer {
    return new ImplementsJSONSerializer(json);
  }
  toJSON(): any {
    return this.json;
  }
}

// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializer);

और अब मुझे पता है कि मेरे T में सभी तरीके उपलब्ध होंगे JSONSerializer । लेकिन यह अत्यधिक क्रियात्मक और तर्क करने में कठिन है (रुको, आप ImplementsJSONSerializer पास कर रहे हैं, लेकिन यह JSONSerializable नहीं है, है ना? रुको, आप डक-टाइपिंग कर रहे हैं ??) . संस्करण के बारे में आसान कारण है:

interface JSONSerializer {
  toJSON(): any;
}

interface JSONSerializable <T extends JSONSerializer> {
  fromJSON(json: any): T;
}

function makeInstance<T extends JSONSerializer>(cls: JSONSerializable<T>): T {
  return cls.fromJSON({});
}

class ImplementsJSONSerializer implements JSONSerializer {
  constructor (private json: any) {
  }
  toJSON(): any {
    return this.json;
  }
}

class ImplementsJSONSerializable implements JSONSerializable<ImplementsJSONSerializer> {
  fromJSON(json: any): ImplementsJSONSerializer {
    return new ImplementsJSONSerializer(json);
  }

}

// returns an instance of ImplementsJSONSerializable
makeInstance(new ImplementsJSONSerializable());

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

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

तो दूसरे शब्दों में, आपके पास एक वर्ग हो सकता है जिसमें स्थिर fromJSON हो और जिनके उदाहरणों में toJSON हो:

interface JSONSerializer {
    toJSON(): any;
}

interface JSONSerializable<T extends JSONSerializer> {
    fromJSON(json: any): T;
}

function makeInstance<T extends JSONSerializer>(cls: JSONSerializable<T>): T {
    return cls.fromJSON({});
}

class ImplementsJSONSerializer {
    constructor (private json: any) {
    }
    static fromJSON(json: any): ImplementsJSONSerializer {
        return new ImplementsJSONSerializer(json);
    }
    toJSON(): any {
        return this.json;
    }
}


// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializer);

@mhegazy मैंने पहले ही बताया कि एक व्यवहार्य विकल्प के रूप में। मेरा पहला 'बतख-टाइपिंग' उदाहरण देखें। मैंने तर्क दिया कि यह अनावश्यक रूप से क्रियात्मक है और इसके बारे में तर्क करना कठिन है। मैंने तब जोर देकर कहा कि जिस संस्करण के बारे में तर्क करना आसान है (कारखाना वर्ग) और भी अधिक क्रियात्मक है।

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

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

मैंने तब जोर देकर कहा कि जिस संस्करण के बारे में तर्क करना आसान है (कारखाना वर्ग)

मुझे यकीन नहीं है कि मैं सहमत हूं कि इसके बारे में तर्क करना आसान है।

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

और यह समस्या इसे जोड़े जाने पर नज़र रख रही है। मैं बस यह सुनिश्चित करना चाहता था कि इस थ्रेड के भविष्य के आगंतुक यह समझें कि यह आज implements क्लॉज के बिना संभव है।

@kitsonk ठीक है मुझे वह याद आया।

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

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

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

यहां:

export interface LocationModuleInterface {
  readonly name: string;

  getRecreationOptions(): ModuleRecreationOptions;
}

export abstract class AbstractLocationModule implements LocationModuleInterface {
  abstract readonly name: string;

  abstract getRecreationOptions(): ModuleRecreationOptions;

  abstract static recreateFromOptions(options: ModuleRecreationOptions): AbstractLocationModule;
}

और फिर मैं अच्छी तरह से ठोकर खाता हूं, स्थिर सार के साथ नहीं हो सकता। और यह इंटरफ़ेस में नहीं हो सकता।

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

मुझे टाइपस्क्रिप्ट बहुत पसंद है। पागलों की तरह मेरा मतलब है। लेकिन हमेशा होता है लेकिन।

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

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

मेरे कारखाने को रनटाइम स्थिर विधि अस्तित्व की जांच करनी होगी। वह भी कैसे?

या इससे भी बेहतर:

export interface LocationModuleInterface {
  readonly name: string;

  getRecreationOptions(): ModuleRecreationOptions;
  dontForgetToHaveStaticMethodForRecreation();
}

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

@मालिना-किर्न

मेरा पहला 'बतख-टाइपिंग' उदाहरण देखें।

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

@aluanhaddad आपका निहितार्थ सही नहीं है। मैं आपकी बात समझ सकता हूं कि implements ISomeInterface प्राथमिक कार्य वर्ग वस्तु को बहुरूपी रूप से उपयोग करने के लिए है। हालांकि इससे कोई फर्क नहीं पड़ता कि क्या वर्ग इंटरफ़ेस का संदर्भ देता है जो क्लास ऑब्जेक्ट के स्थिर आकार का वर्णन करता है।

आप इंगित करते हैं कि निहित प्रकार का अनुमान और उपयोग साइट त्रुटियां सभी उपयोग मामलों को कवर करती हैं।
इस उदाहरण पर विचार करें:

interface IComponent<TProps> {
    render(): JSX.Element;
}

type ComponentStaticDisplayName = 'One' | 'Two' | 'Three' | 'Four';
interface IComponentStatic<TProps> {
    defaultProps?: Partial<TProps>;
    displayName: ComponentStaticDisplayName;
    hasBeenValidated: 'Yes' | 'No';
    isFlammable: 'Yes' | 'No';
    isRadioactive: 'Yes' | 'No';
    willGoBoom: 'Yes' | 'No';
}

interface IComponentClass<TProps> extends IComponentStatic<TProps> {
    new (): IComponent<TProps> & IComponentStatic<TProps>;
}

function validateComponentStaticAtRuntime<TProps>(ComponentStatic: IComponentStatic<TProps>, values: any): void {
    if(ComponentStatic.isFlammable === 'Yes') {
        // something
    } else if(ComponentStatic.isFlammable === 'No') {
        // something else
    }
}

// This works, we've explicitly described the object using an interface
const componentStaticInstance: IComponentStatic<any> = {
    displayName: 'One',
    hasBeenValidated: 'No',
    isFlammable: 'Yes',
    isRadioactive: 'No',
    willGoBoom: 'Yes'
};

// Also works
validateComponentStaticAtRuntime(componentStaticInstance, {});

class ExampleComponent1 implements IComponent<any> {
    public render(): JSX.Element { return null; }

    public static displayName = 'One'; // inferred as type string
    public static hasBeenValidated = 'No'; // ditto ...
    public static isFlammable = 'Yes';
    public static isRadioactive = 'No';
    public static willGoBoom = 'Yes';
}

// Error: " ... not assignable to type IComponentStatic<..> ... "
validateComponentStaticAtRuntime(ExampleComponent1, {});

class ExampleComponent2 implements IComponent<any> {
    public render(): JSX.Element { return null; }

    public static displayName = 'One';
    public static hasBeenValidated = 'No';
    public static isFlammable = 'Yes';
    public static isRadioactive = 'No';
    public static willGoBoom = 'Yes';
}

// Error: " ... not assignable to type IComponentStatic<..> ... "
validateComponentStaticAtRuntime(ExampleComponent2, {});

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

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

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

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

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

अन्य पोस्ट परिभाषा साइट पर चेक को आकार देने के लिए #workarounds का सुझाव देते हैं। हालांकि ये खतरनाक समाधान आपको परिभाषा स्थल पर आकार की जांच करने की अनुमति देंगे (कुछ मामलों में), कुछ समस्याएं हैं:

• वे ऊपर नंबर 1 को हल नहीं करते हैं, फिर भी आपको हर वर्ग में प्रत्येक सदस्य के प्रकार को स्पष्ट रूप से घोषित करने की आवश्यकता होगी।
• कई मामलों में उनमें स्पष्टता, लालित्य और पठनीयता का अभाव होता है। वे हमेशा उपयोग करने में आसान नहीं होते हैं, सहज नहीं होते हैं, और यह पता लगाने में काफी समय लग सकता है कि वे संभव हैं।
• वे सभी मामलों में काम नहीं करते हैं और #workaroundsToMakeTheWorkaroundsWork खोजना मज़ेदार या उत्पादक नहीं है... लेकिन ज़्यादातर मज़ेदार नहीं है।

यहाँ समाधान का एक उदाहरण है जिसे मैंने हाल ही में परिभाषा स्थल पर आकार जाँच के लिए बाध्य करने के लिए देखा है ...

// (at least) two separate interfaces
interface ISomeComponent { ... }
interface ISomeComponentClass { ... }

// confusing workaround with extra work to use, not very intuitive, etc
export const SomeComponent: ISomeComponentClass =
class SomeComponent extends Component<IProps, IState> implements ISomeComponent {
...
}

अब उस वर्कअराउंड का उपयोग करने का प्रयास करें जिसमें एक अमूर्त वर्ग फेंका गया हो

interface ISomeComponent { ... }
// need to separate the static type from the class type, because the abstract class won't satisfy
// the shape check for new(): ... 
interface ISomeComponentStatic { ... }
interface ISomeComponentClass { 
    new (): ISomeComponent & ISomeComponentStatic;
}

// I AM ERROR.    ... cannot find name abstract
export const SomeComponentBase: ISomeComponentStatic =
abstract class SomeComponentBase extends Component<IProps, IState> implements ISomeComponent {
...
}

export const SomeComponent: ISomeComponentClass =
class extends SomeComponentBase { ... }

मुझे लगता है कि हम उसके आसपास भी काम करेंगे... आह

...

abstract class SomeComponentBaseClass extends Component<IProps, IState> implements ISomeComponent { 
   ... 
}

// Not as nice since we're now below the actual definition site and it's a little more verbose
// but hey at least were in the same module and we can check the shape if the use site is in
// external code...
// We now have to decide if we'll use this work around for all classes or only the abstract ones
// and instead mix and match workaround syntax
export const SomeComponentBase: ISomeComponentStatic = SomeComponentBaseClass;

लेकिन रुकिए, और भी बहुत कुछ है! आइए देखें कि क्या होता है यदि हम जेनरिक का उपयोग कर रहे हैं ....

interface IComponent<TProps extends A> { ... }
interface IComponentStatic<TProps extends A> { ... }

interface IComponentClass<TProps extends A, TOptions extends B> extends IComponentStatic<TProps> {
    new (options: TOptions): IComponent<TProps> & IComponentStatic<TProps>;
}

abstract class SomeComponentBaseClass<TProps extends A, TOptions extends B> extends Component<TProps, IState> implements IComponent<TProps> {
...
}

// Ruh Roh Raggy: "Generic type .... requires 2 type argument(s) ..."
export const SomeComponentBase: IComponentStatic = SomeComponentBaseClass;


// "....  requires 1 type argument(s) ... "    OH NO, We need a different workaround
export const SomeComponent: IComponentStatic =
class extends SomeComponentBase<TProps extends A, ISomeComponentOptions> {
...
}

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

यदि आप साइट का उपयोग कर रहे हैं तो समुदाय/अनुरक्षकों को इंटरफ़ेस सदस्यों के लिए static संशोधक को स्वीकार करने के लिए बाहरी रूप से मनाएं। और इस बीच आपको एक और समाधान की आवश्यकता होगी। यह परिभाषा साइट पर नहीं है, लेकिन मेरा मानना ​​है कि आप इसे प्राप्त करने के लिए #8328 में वर्णित वर्कअराउंड के संशोधित संस्करण का उपयोग कर सकते हैं। 16 मई 2016 को @RyanCavanaugh . के सौजन्य से @mhegazy की टिप्पणी में समाधान देखें

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

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

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

यह Java से C# पर स्विच करने की याद दिलाता है। जब मैंने पहली बार C# कोड को ऐसा करते देखा था
C# var something = "something"; if(something == "something") { ... }
मेरे सिर में खतरे की घंटी बजने लगी, दुनिया खत्म हो रही थी, उन्हें "something".Equals(something) आदि का उपयोग करने की आवश्यकता थी

== संदर्भ के लिए बराबर है! स्ट्रिंग तुलना के लिए आपके पास एक अलग .Equals(...) है...
और स्ट्रिंग अक्षर को पहले आने की जरूरत है ताकि आपको एक शून्य रेफरी कॉलिंग न मिले। एक शून्य चर पर बराबर (...) ...
और... और... हाइपरवेंटीलेटिंग

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

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

मैं अगली टिप्पणी में abstract static पर ध्यान दूंगा....

इंटरफेस को हमेशा इम्प्लांटिंग कक्षाओं पर सदस्य प्रकारों के पुनर्विक्रय की आवश्यकता होती है। (_explicitly_ कार्यान्वयन कक्षाओं में सदस्य हस्ताक्षरों का अनुमान एक अलग, अभी तक असमर्थित, विशेषता है)।

आपको त्रुटियाँ मिलने का कारण इस प्रस्ताव से असंबंधित है। इसके आसपास जाने के लिए, आपको वर्ग के सदस्यों के कार्यान्वयन पर readonly संशोधक का उपयोग करने की आवश्यकता है, स्थिर या अन्यथा, जो कि शाब्दिक प्रकार के होने की आवश्यकता है; अन्यथा, string का अनुमान लगाया जाएगा।

फिर से implements कीवर्ड केवल इरादे का एक विनिर्देश है, यह प्रकारों की संरचनात्मक संगतता को प्रभावित नहीं करता है, न ही नाममात्र टाइपिंग का परिचय देता है। यह कहना नहीं है कि यह उपयोगी नहीं हो सकता है लेकिन यह प्रकारों को नहीं बदलता है।

तो abstract static ... इसके लायक नहीं। बहुत सारी समस्याएं।

आपको यह घोषित करने के लिए नए और जटिल सिंटैक्स की आवश्यकता होगी कि उपयोग साइट पर पहले से ही क्या जांचा जाएगा (यदि उपयोग साइट टाइपस्क्रिप्ट कंपाइलर द्वारा चेक की जाएगी)।

यदि उपयोग साइट बाहरी है तो आपको वास्तव में एक इंटरफ़ेस के static सदस्यों की आवश्यकता है ... क्षमा करें प्लगिंग ... और शुभ रात्रि!

@aluanhaddad सच है, लेकिन भले ही स्पष्ट रूप से लागू करने वाली कक्षाओं में सदस्य हस्ताक्षरों का अनुमान एक समर्थित सुविधा थी, हमारे पास कक्षा के स्थिर पक्ष के लिए सदस्य हस्ताक्षर घोषित करने के स्वच्छ तरीकों की कमी है।

जिस बिंदु को मैं व्यक्त करने की कोशिश कर रहा था वह यह था कि हमारे पास explicitly वर्ग के स्थिर पक्ष की अपेक्षित संरचना घोषित करने के तरीकों की कमी है और ऐसे मामले हैं जहां यह मायने रखता है (या सुविधाओं का समर्थन करने के लिए मायने रखता है)

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

मैं एक उदाहरण के रूप में टाइप अनुमान का उपयोग करने की कोशिश कर रहा था कि यह भविष्य के समर्थन के साथ क्यों मायने रखता है।
यहां इंटरफ़ेस को वाक्यात्मक रूप से संदर्भित करके let something: ISomethingStatic = { isFlammable: 'Ys', isFlammable2: 'No' ... isFlammable100: 'No' } हमें इस प्रकार को 'हां' के रूप में स्पष्ट रूप से घोषित करने की आवश्यकता नहीं है | 'नहीं' 100 अलग-अलग बार।

एक वर्ग के स्थिर पक्ष (भविष्य में) के लिए एक ही प्रकार के अनुमान को प्राप्त करने के लिए हमें इंटरफ़ेस को वाक्यात्मक रूप से संदर्भित करने के लिए किसी तरह की आवश्यकता होगी।

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

कुछ वाचालता की कीमत पर, आप एक सभ्य स्तर की सुरक्षा प्राप्त कर सकते हैं:

type HasType<T, Q extends T> = Q;

interface IStatic<X, Y> {
    doWork: (input: X) => Y
}

type A_implments_IStatic<X, Y> = HasType<IStatic<X, Y>, typeof A>    // OK
type A_implments_IStatic2<X> = HasType<IStatic<X, number>, typeof A> // OK
type A_implments_IStatic3<X> = HasType<IStatic<number, X>, typeof A> // OK
class A<X, Y> {
    static doWork<T, U>(_input: T): U {
        return null!;
    }
}

type B_implments_IStatic = HasType<IStatic<number, string>, typeof B> // Error as expected
class B {
    static doWork(n: number) {
        return n + n;
    }
}

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

export abstract class Component {
  public abstract static READ_FROM(buffer: ByteBuffer): Component;
}

// I want to force my DeckComponent class to implement it's own static ReadFrom method
export class DeckComponent extends Component {
  public cardIds: number[];

  constructor(cardIds: number[]) {
    this.cardIds = cardIds;
  }

  public static READ_FROM(buffer: ByteBuffer): DeckComponent {
    const cardIds: number[] = [...];
    return new DeckComponent(cardIds);
  }
}

@RyanCavanaugh मुझे नहीं लगता कि किसी ने अभी तक इसका उल्लेख किया है (हालाँकि मैं इसे अपने त्वरित रीड-थ्रू में याद कर सकता था), लेकिन इसके जवाब में:

इस पर विचार करते समय हमारे पास एक प्रमुख प्रश्न था: अमूर्त स्थैतिक विधि को कॉल करने की अनुमति किसे है? संभवतः आप AbstractParentClass.getSomeClassDependentValue को सीधे लागू नहीं कर सकते। लेकिन क्या आप AbstractParentClass प्रकार की अभिव्यक्ति पर विधि लागू कर सकते हैं? यदि हां, तो इसकी अनुमति क्यों दी जानी चाहिए? यदि नहीं, तो सुविधा का क्या उपयोग है?

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

तो मैं जो प्रस्ताव दूंगा वह T.constructor प्रकार Function & {{ statics on T }} दे रहा है। यह अमूर्त वर्गों को अनुमति देगा जो abstract static foo फ़ील्ड को this.constructor.foo के माध्यम से सुरक्षित रूप से एक्सेस करने के लिए घोषित करते हैं, जबकि कन्स्ट्रक्टर असंगतताओं के साथ समस्याएं पैदा नहीं करते हैं।

और यहां तक ​​​​कि अगर T.constructor में स्टैटिक्स को स्वचालित रूप से जोड़ना लागू नहीं किया जाता है, तब भी हम मैन्युअल रूप से "constructor": typeof AbstractParentClass घोषित करके बेस क्लास में abstract static गुणों का उपयोग करने में सक्षम होंगे।

मुझे लगता है कि बहुत से लोग उम्मीद करते हैं कि @ patryk-zielinski93 उदाहरण काम करना चाहिए। इसके बजाय, हमें काउंटरइंट्यूटिव, वर्बोज़ और क्रिप्टिक वर्कअराउंड का उपयोग करना चाहिए। चूंकि हमारे पास पहले से ही 'सिंटैक्स शुगरेड' वर्ग और स्थिर सदस्य हैं, इसलिए हमारे पास टाइप सिस्टम में ऐसी चीनी क्यों नहीं हो सकती है?

यहाँ मेरा दर्द है:

abstract class Shape {
    className() {
        return (<typeof Shape>this.constructor).className;
    }
    abstract static readonly className: string; // How to achieve it?
}

class Polygon extends Shape {
    static readonly className = 'Polygon';
}

class Triangle extends Polygon {
    static readonly className = 'Triangle';
}

हो सकता है कि हम इसके बजाय/समानांतर में static implements क्लॉज पेश कर सकें? जैसे

interface Foo {
    bar(): number;
}

class Baz static implements Foo {
    public static bar() {
        return 4;
    }
}

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

( statically implements बेहतर होगा, लेकिन यह एक नया कीवर्ड पेश करता है। अगर यह इसके लायक है तो बहस योग्य है। हालांकि, यह प्रासंगिक हो सकता है।)

ओपी के प्रस्ताव के बारे में संदेह करने वालों के तर्कों को समझने की मैंने कितनी भी कोशिश की, मैं असफल रहा।

केवल एक व्यक्ति (https://github.com/Microsoft/TypeScript/issues/14600#issuecomment-379645122) ने आपको @RyanCavanaugh उत्तर दिया। मैंने इसे थोड़ा साफ करने के लिए और आपके प्रश्न और मेरे उत्तरों को स्पष्ट करने के लिए ओपी के कोड को फिर से लिखा:

abstract class Base {
  abstract static foo() // ref#1
}

class Child1 extends Base {
  static foo() {...} // ref#2
}

class Child2 extends Base {
  static foo() {...}
}

अमूर्त स्थैतिक विधि को कॉल करने की अनुमति किसे है? संभवतः आप सीधे Base.foo आह्वान नहीं कर सकते

यदि आपका मतलब रेफरी # 1 है, तो हाँ, इसे कभी भी कॉल करने योग्य नहीं होना चाहिए, क्योंकि अच्छी तरह से यह सार है, और इसमें शरीर भी नहीं है।
आपको केवल रेफरी # 2 पर कॉल करने की अनुमति है।

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

function bar(baz:Base) { // "expression of type Base"
  baz.foo() // ref#3
}

function bar2(baz: typeof Base) { // expression of type Base.constructor
  baz.foo() // ref#4
}

रेफरी # 3 एक त्रुटि है। नहीं, आप वहां "foo" का आह्वान नहीं कर सकते, क्योंकि baz को Child1 या Child2 का __instance__ माना जाता है, और उदाहरणों में स्थिर विधियां नहीं होती हैं

रेफरी # 4 सही है (होना चाहिए)। आप वहां स्थिर विधि फू का आह्वान कर सकते हैं (सक्षम होना चाहिए), क्योंकि baz को चाइल्ड 1 या चाइल्ड 2 का निर्माता माना जाता है, जो दोनों बेस का विस्तार करते हैं और इसलिए फू () को लागू करना चाहिए।

bar2(Child1) // ok
bar2(Child2) // ok

आप इस स्थिति की कल्पना कर सकते हैं:

bar2(Base) // ok, but ref#4 should be red-highlighted with compile error e.g. "Cannot call abstract  method." 
// Don't know if it's possible to implement in compiler, though. 
// If not, compiler simply should not raise any error and let JS to do it in runtime (Base.foo is not a function). 

सुविधा का क्या उपयोग है?

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

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

pps मैंने अपने कोड के साथ अनुपालन करने के लिए आपके प्रश्नों में वर्ग और विधि के नाम संपादित किए।

अन्य संशयवादियों के मुख्य तर्कों के आधार पर कुछ विचार:

"नहीं, इसे लागू नहीं किया जाना चाहिए, लेकिन आप इसे पहले से ही इस तरह से कर सकते हैं * कोड की 15 गुना अधिक लाइनें लिखता है *"।

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

"जेएस कक्षाओं के लिए दो इंटरफेस हैं: कन्स्ट्रक्टर और इंस्टेंस के लिए"।

ठीक है, क्यों न हमें कंस्ट्रक्टर के लिए इंटरफ़ेस बनाने का तरीका दिया जाए? हालाँकि केवल उस static शब्द को जोड़ना बहुत आसान और अधिक सहज है।

और इसके बारे में:

जब तक हम इस पर और प्रतिक्रिया नहीं सुन लेते, तब तक इस पर रोक लगाते रहें।

एक वर्ष से अधिक समय बीत चुका है, और बहुत सारी प्रतिक्रियाएँ प्रदान की गई हैं, इस मुद्दे को कब तक रोके रखा जाएगा? क्या कोई जवाब दे सकता है, कृपया।

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

संभव उपाय?

export type Constructor<T> = new (...args: any[]) => T;

declare global {
  interface Function extends StaticInterface {
  }
}

export interface StaticInterface {
  builder: (this: Constructor<MyClass>) => MyClass
}

// TODO add decorator that adds "builder" implementation
export class MyClass {
  name = "Ayyy"
}

export class OtherClass {
  id = "Yaaa"
}

MyClass.builder() // ok
OtherClass.builder() // error

प्रस्ताव: इंटरफेस और प्रकारों में स्थिर सदस्य, और अमूर्त वर्ग में अमूर्त सदस्य, v2

बक्सों का इस्तेमाल करें

फैंटेसीलैंड के अनुरूप प्रकार

```` टाइपप्रति
इंटरफ़ेस लागू लागू होता है {स्थिर (ए: ए): लागू ; }

const of = >(c: C, a: A): new C => c.of(a); ````

Serializable स्थिर deserialize विधि के साथ टाइप करें

```` टाइपप्रति
इंटरफ़ेस सीरियल करने योग्य {
स्थैतिक deserialize(s: string): Serializable;

serialize(): string;

}
````

सामान्य तौर पर अनुबंध

```` टाइपप्रति
इंटरफ़ेस अनुबंध {
स्थिर बनाएँ (x: संख्या): अनुबंध;
स्थिर नया (x: संख्या): अनुबंध;
}

कास्ट फ़ैक्टरी 1 = (सी: स्थिर अनुबंध): अनुबंध => सी.क्रिएट (मैथ.रैंडम ());
कास्ट फ़ैक्टरी 2 = (सी: स्थिर अनुबंध): अनुबंध => नया सी (गणित। यादृच्छिक ());
कास्ट फैक्ट्री3 =(सी: सी): नया सी => सी.क्रिएट (मैथ.रैंडम ());

कास्ट c1 = फ़ैक्टरी 1 (ContractImpl); // Contract
const c2 = factory2 (ContractImpl); // Contract
const c3 = factory3 (ContractImpl); // ContractImpl
````

वाक्य - विन्यास

स्थिर तरीके और क्षेत्र

```` टाइपप्रति
इंटरफ़ेस सीरियल करने योग्य {
स्थिर deserialize(s: string): Serializable;
}

सीरियल करने योग्य टाइप करें = {
स्थिर deserialize(s: string): Serializable;
};

सार वर्ग सीरियल करने योग्य {
स्थिर सार deserialize (ओं: स्ट्रिंग): Serializable;
}
````

स्टेटिक कंस्ट्रक्टर हस्ताक्षर

typescript interface Contract { static new(): Contract; }

फॉलो-ऑन: स्टेटिक कॉल सिग्नेचर

चर्चा करना:

स्थिर कॉल हस्ताक्षर कैसे व्यक्त किए जा सकते हैं?
अगर हम उन्हें कॉल सिग्नेचर से पहले केवल static संशोधक जोड़कर व्यक्त करेंगे,
हम उन्हें 'static' नाम के इंस्टेंस मेथड से कैसे अलग करेंगे?
क्या हम 'new' -नामित विधियों के समान समाधान का उपयोग कर सकते हैं?
ऐसे में यह निश्चित तौर पर एक क्रांतिकारी बदलाव होगा।

static टाइप ऑपरेटर

typescript const deserialize = (Class: static Serializable, s: string): Serializable => Class.deserialize(s);

new टाइप ऑपरेटर

typescript const deserialize = <C extends static Serializable>(Class: C, s: string): new C => Class.deserialize(s);

आंतरिक स्लॉट

[[Static]] आंतरिक स्लॉट

एक प्रकार का "स्टेटिक" इंटरफ़ेस [[Static]] आंतरिक स्लॉट में संग्रहीत किया जाएगा:

```` टाइपप्रति
// प्रारूप
इंटरफ़ेस सीरियल करने योग्य {
स्थिर deserialize(s: string): Serializable;
क्रमबद्ध करें: स्ट्रिंग;
}

// आंतरिक रूप से दर्शाया जाएगा
// इंटरफ़ेस सीरियल करने योग्य {
// [[स्थिर]]: {
// [[इंस्टेंस]]: सीरियल करने योग्य; // नीचे देखें।
// deserialize (s: स्ट्रिंग): Serializable;
//};
// क्रमबद्ध करें (): स्ट्रिंग;
// }
````

डिफ़ॉल्ट रूप से never टाइप करें।

[[Instance]] आंतरिक स्लॉट

प्रकार का "इंस्टेंस" इंटरफ़ेस संग्रहीत किया जाएगा
[[Instance]] [[Static]] आंतरिक स्लॉट प्रकार के आंतरिक स्लॉट में।

डिफ़ॉल्ट रूप से never टाइप करें।

अर्थ विज्ञान

static ऑपरेटर के बिना

जब एक प्रकार का उपयोग मूल्य प्रकार के रूप में किया जाता है,
[[Static]] आंतरिक स्लॉट को छोड़ दिया जाएगा:

```` टाइपप्रति
कॉन्स्टेबल घोषित करें: सीरियल करने योग्य;

टाइप टी = क्रमबद्ध करने योग्य टाइप करें;
// {क्रमबद्ध करें (): स्ट्रिंग; }
````

लेकिन प्रकार ही रहता है [[Static]] आंतरिक स्लॉट:

typescript type T = Serializable; // { // [[Static]]: { // [[Instance]]: Serializable; // deserialize(s: string): Serializable; // }; // serialize(): string; // }

असाइनमेंट:

स्थिर-जागरूक प्रकार के दोनों मान संरचनात्मक रूप से समान के लिए असाइन किए जा सकते हैं
(बेशक [[Static]] को छोड़कर) वाले और इसके विपरीत।

static ऑपरेटर

| सहयोगीता | वरीयता |
| :-----------: | :--------------------------------: |
| सही | आईडीके, लेकिन new के एक के बराबर है |

static प्रकार का ऑपरेटर [[Static]] प्रकार के आंतरिक स्लॉट का प्रकार लौटाता है।
यह कुछ हद तक typeof टाइप ऑपरेटर के समान है,
लेकिन इसका तर्क मान के बजाय एक प्रकार का होना चाहिए।

typescript type T = static Serializable; // { // [[Instance]]: Serializable; // deserialize(s: string): Serializable; // }

typeof प्रकार का ऑपरेटर [[Instance]] आंतरिक स्लॉट को भी त्याग देता है:

```` टाइपप्रति
स्थिरांक SerializableImpl घोषित करें: स्थिर Serializable;

टाइप टी = टाइपऑफ़ SerializableImpl;
// { deserialize (s: string): Serializable; }
````

असाइनमेंट:

उदाहरण-जागरूक प्रकार के दोनों मान संरचनात्मक रूप से समान के लिए असाइन किए जा सकते हैं
( [[Instance]] आंतरिक स्लॉट को छोड़कर, निश्चित रूप से) वाले और इसके विपरीत।

new ऑपरेटर

| सहयोगीता | वरीयता |
| :-----------: | :------------------------------------------: |
| सही | आईडीके, लेकिन static के एक के बराबर है |

new ऑपरेटर [[Instance]] प्रकार के आंतरिक स्लॉट का प्रकार लौटाते हैं।
यह प्रभावी रूप से static ऑपरेटर को उलट देता है:

typescript type T = new static Serializable; // { // [[Static]]: { // [[Instance]]: Serializable; // deserialize(s: string): Serializable; // }; // serialize(): string; // }

extends / implements शब्दार्थ

गैर-डिफ़ॉल्ट [[Static]] आंतरिक स्लॉट के साथ एक इंटरफ़ेस लागू करने वाला वर्ग
एक संगत [[Static]] आंतरिक स्लॉट होना चाहिए।
संगतता जांच समान होनी चाहिए (या इसके समान)
नियमित (उदाहरण) संगतता जांच।

```` टाइपप्रति
वर्ग SerializableImpl Serializable लागू करता है {
स्थैतिक deserialize(s: string): SerializableImpl {
// डिसेरिएलाइज़िंग लॉजिक यहाँ जाता है।
}

// ...other static members
// constructor
// ...other members

serialize(): string {
    //
}

}
````

ऐसा करने के लिए

• [ ] तय करें कि स्थिर कॉल हस्ताक्षरों के लिए किस सिंटैक्स का उपयोग किया जाना चाहिए।
  संभवतः परिवर्तनों को तोड़े बिना।
• [ ] क्या सशर्त प्रकार और infer ऑपरेटर के साथ कोई विशेष मामला है?
• [ ] गैर-अमूर्त वर्ग के सदस्यों के शब्दार्थ में परिवर्तन। _ब्रेकिंग हो सकता है।_

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

मेरे पास मुद्दा यह है कि मैं एक कोड जेनरेटेड क्लास में संशोधन करना चाहता हूं। उदाहरण के लिए मैं क्या करना चाहता हूं:

import {Message} from "../protobuf";

declare module "../protobuf" {
    interface Message {
        static factory: (params: MessageParams) => Message
    }
}

Message.factory = function(params: MessageParams) {
    const message = new Message();
    //... set up properties
    return message;
}

export default Message;

मुझे एक भी वर्कअराउंड नहीं मिल रहा है जो मुझे टीएस के वर्तमान संस्करण के साथ इसके बराबर करने की अनुमति देता है। क्या मुझे वर्तमान में इस समस्या को हल करने का कोई तरीका याद आ रहा है?

यह यहां उपयोग के मामले के रूप में पोस्ट करने के लिए प्रासंगिक लगता है जिसके लिए स्पष्ट रूप से कोई कामकाज नहीं है और निश्चित रूप से कोई सीधा कामकाज नहीं है।

यदि आप इंटरफेस के खिलाफ कक्षा के उदाहरण और स्थिर पक्ष की जांच करना चाहते हैं, तो आप इसे इस तरह कर सकते हैं:

interface C1Instance {
  // Instance properties ...

  // Prototype properties ...
}
interface C2Instance extends C1Instance {
  // Instance properties ...

  // Prototype properties ...
}

interface C1Constructor {
  new (): C1Instance;

  // Static properties ...
}
interface C2Constructor {
  new (): C2Instance;

  // Static properties ...
}

type C1 = C1Instance;
let C1: C1Constructor = class {};

type C2 = C2Instance;
let C2: C2Constructor = class extends C1 {};

let c1: C1 = new C1();
let c2: C2 = new C2();

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

किसी भी भाषा के साथ बात, प्राकृतिक और कृत्रिम दोनों, कि यह स्वाभाविक रूप से कुशल और उपयोग के लिए आकर्षक होने के लिए विकसित होनी चाहिए। अंततः लोगों ने भाषा में कटौती का उपयोग करने का फैसला किया, ("ओके" => "ओके", "गोइंग टू" => "गोना"), "सेल्फी" और "गूगल" जैसे नए हास्यास्पद शब्दों का आविष्कार किया, वर्तनी को l33tspeak के साथ फिर से परिभाषित किया और सामान, और यहां तक ​​​​कि कुछ शब्दों पर प्रतिबंध लगा दिया, और, भले ही आप उनका उपयोग करना चाहते हैं या नहीं, फिर भी हर कोई थोड़े से समझता है कि उनका क्या मतलब है, और हम में से कुछ कुछ विशेष कार्यों को प्राप्त करने के लिए उनका उपयोग करते हैं। और उनमें से किसी के लिए कोई अच्छा कारण नहीं हो सकता है, लेकिन कुछ कार्यों में कुछ लोगों की दक्षता, यह उन लोगों की संख्या का सवाल है, जो वास्तव में उनका उपयोग करते हैं। इस बातचीत की मात्रा स्पष्ट रूप से दिखाती है, कि बहुत सारे लोग इस static abstract का उपयोग कर सकते हैं, जो भी उनके मन में हैं। मैं यहां उसी कारण से आया था, 'क्योंकि मैं Serializable को लागू करना चाहता था इसलिए मैंने इसे करने के सभी सहज (मेरे लिए) तरीकों की कोशिश की, और उनमें से कोई भी काम नहीं करता है। मेरा विश्वास करो, आखिरी चीज जो मैं ढूंढूंगा वह स्पष्टीकरण है कि मुझे इस सुविधा की आवश्यकता क्यों नहीं है और कुछ और के लिए जाना चाहिए। डेढ़ साल, यीशु मसीह! मुझे यकीन है कि परीक्षण और सामान के साथ कहीं न कहीं पहले से ही एक पीआर है। कृपया ऐसा करें, और यदि उपयोग का एक निश्चित तरीका है जिसे हतोत्साहित किया जाता है, तो हमारे पास उसके लिए एक tslint है।

this.constructor.staticMember के माध्यम से बेस क्लास से बाल वर्गों के स्थिर सदस्यों तक पहुंच बनाना संभव है, इसलिए अमूर्त स्थिर सदस्य मुझे समझ में आते हैं।

class A {
  f() {
    console.log(this.constructor.x)
  }
}

class B extends A {
  static x = "b"
}

const b = new B
b.f() // logs "b"

कक्षा ए को यह निर्दिष्ट करने में सक्षम होना चाहिए कि उसे स्थिर x सदस्य की आवश्यकता है, क्योंकि यह इसे f विधि में उपयोग करता है।

कोई ख़बर ?
सुविधाओं की वास्तव में आवश्यकता है
1) static इंटरफेस में कार्य करता है
2) abstract static अमूर्त कक्षाओं में कार्य करता है

हालांकि मुझे स्थिर इंटरफेस रखने के विचार से नफरत है लेकिन सभी व्यावहारिक उद्देश्यों के लिए निम्नलिखित आज पर्याप्त होना चाहिए:

type MyClass =  (new (text: string) => MyInterface) & { myStaticMethod(): string; }

जिसका उपयोग इस प्रकार किया जा सकता है:

const MyClass: MyClass = class implements MyInterface {
   constructor(text: string) {}
   static myStaticMethod(): string { return ''; }
}

अपडेट करें:

विचार और एक जीवंत उदाहरण पर अधिक जानकारी:

// dynamic part
interface MyInterface {
    data: number[];
}
// static part
interface MyStaticInterface {
    myStaticMethod(): string;
}

// type of a class that implements both static and dynamic interfaces
type MyClass = (new (data: number[]) => MyInterface) & MyStaticInterface;

// way to make sure that given class implements both 
// static and dynamic interface
const MyClass: MyClass = class MyClass implements MyInterface {
   constructor(public data: number[]) {}
   static myStaticMethod(): string { return ''; }
}

// works just like a real class
const myInstance = new MyClass([]); // <-- works!
MyClass.myStaticMethod(); // <-- works!

// example of catching errors: bad static part
/*
type 'typeof MyBadClass1' is not assignable to type 'MyClass'.
  Type 'typeof MyBadClass1' is not assignable to type 'MyStaticInterface'.
    Property 'myStaticMethod' is missing in type 'typeof MyBadClass1'.
*/
const MyBadClass1: MyClass = class implements MyInterface {
   constructor(public data: number[]) {}
   static myNewStaticMethod(): string { return ''; }
}

// example of catching errors: bad dynamic part
/*
Type 'typeof MyBadClass2' is not assignable to type 'MyClass'.
  Type 'typeof MyBadClass2' is not assignable to type 'new (data: number[]) => MyInterface'.
    Type 'MyBadClass2' is not assignable to type 'MyInterface'.
      Property 'data' is missing in type 'MyBadClass2'.
*/
const MyBadClass2: MyClass = class implements MyInterface {
   constructor(public values: number[]) {}
   static myStaticMethod(): string { return ''; }
}

@ एलेक्सी-बायकोव यह टाइपस्क्रिप्ट की गलती नहीं हो सकती है, लेकिन मुझे यह काम करने वाले कोणीय घटक सज्जाकार और उनके एओटी कंपाइलर नहीं मिल सके।

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

// no errors
class Thing extends MyClass {

}

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

@bbugh मैं यहां चर्चा की जा रही समस्या के अस्तित्व पर सवाल उठाता हूं, यदि नियमित कक्षाओं के उदाहरणों के माध्यम से ऐसा किया जा सकता है तो आपको स्थिर अमूर्त विरासत विधियों के साथ इन सभी परेशानियों की आवश्यकता क्यों होगी?

class MyAbstractStaticClass {
    abstract static myStaticMethod(): void; // <-- wish we could
}
class MyStaticClass extends MyAbstractStaticClass {
    static myStaticMethod(): void {
         console.log('hi');
    }
}
MyStaticClass.myStaticMethod(); // <-- would be great

बनाम

class MyAbstractNonStaticClass {
    abstract myAbstractNonStaticMethod(): void;
}
class MyNonStaticClass extends MyAbstractNonStaticClass {
    myNonStaticMethod(): void {
        console.log('hi again');
    }
}
new MyNonStaticClass().myNonStaticMethod(); // <-- works today

@ एलेक्सी-बायकोव बहुत सारे कारण हैं। उदाहरण के लिए (@ patryk-zielinski93 से ):

abstract class Serializable {  
    abstract serialize (): Object;  
    abstract static deserialize (Object): Serializable;  
}  

मैं Serializable के उपवर्गों में स्थैतिक deserialize विधि के कार्यान्वयन को बाध्य करना चाहता हूँ।
क्या इस तरह के व्यवहार को लागू करने के लिए कोई समाधान है?

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

बस वांछित तर्क को एक अलग वर्ग में ले जाएं, क्योंकि एक स्थिर deserialize विधि होने का कोई लाभ नहीं है जो बहुत ही वर्ग से deserialized जा रहा है

class Deserializer {
     deserializeThis(...): Xxx {}
     deserializeThat(...): Yyy {}
}

समस्या क्या है?

@ एलेक्सी-बायकोव अलग वर्ग सुंदर नहीं दिखता है

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

@octaharon पूरी तरह से डिसेरिएलाइज़ेशन के लिए समर्पित एक वर्ग है जो आपने जो कहा है, उसके बिल्कुल विपरीत है, इसकी एक ही ज़िम्मेदारी है क्योंकि जब आप इसे बदलते हैं तो केवल तभी जब आप डिसेरिएलाइज़ेशन की परवाह करते हैं

इसके विपरीत कक्षा में अक्रमांकन जोड़ने से जैसा आपने प्रस्तावित किया है, यह एक अतिरिक्त जिम्मेदारी देता है और बदले जाने का अतिरिक्त कारण देता है

अंत में मुझे स्थिर विधियों में कोई समस्या नहीं है, लेकिन मैं अमूर्त स्थैतिक विधियों और स्थिर इंटरफेस के लिए व्यावहारिक उपयोग के मामले का एक उदाहरण देखने के लिए वास्तव में उत्सुक हूं

@octaharon पूरी तरह से डिसेरिएलाइज़ेशन के लिए समर्पित एक वर्ग है जो आपने जो कहा है, उसके बिल्कुल विपरीत है, इसकी एक ही ज़िम्मेदारी है क्योंकि जब आप इसे बदलते हैं तो केवल तभी जब आप डिसेरिएलाइज़ेशन की परवाह करते हैं

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

इसके विपरीत कक्षा में अक्रमांकन जोड़ने से जैसा आपने प्रस्तावित किया है, यह एक अतिरिक्त जिम्मेदारी देता है और बदले जाने का अतिरिक्त कारण देता है

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

कितनी फाइलें शामिल हैं, इसके बारे में एकल जिम्मेदारी कुछ नहीं कहती है, यह केवल यह कहती है कि एक ही कारण होना चाहिए

मैं जो कह रहा हूं वह यह है कि जब आप एक नया वर्ग जोड़ते हैं तो आपका मतलब केवल deserialized होने के अलावा किसी और चीज के लिए होता है, इसलिए इसके अस्तित्व का एक कारण होता है और इसे जिम्मेदारी सौंपी जाती है; फिर आप खुद को deserialize करने में सक्षम होने की एक और जिम्मेदारी जोड़ते हैं, यह हमें 2 जिम्मेदारियां देता है, यह SOLID का उल्लंघन करता है, यदि आप इसमें और सामान जोड़ते रहते हैं जैसे रेंडर, प्रिंट, कॉपी, ट्रांसफर, एन्क्रिप्ट, आदि आपको एक गॉड क्लास मिलेगा

और मुझे आपको प्रतिबंध बताने के लिए क्षमा करें, लेकिन लाभ और व्यावहारिक उपयोग के मामलों के बारे में प्रश्न (और उत्तर) इस सुविधा प्रस्ताव को लागू करने के लिए प्रेरित करते हैं

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

यार, कोई भी अच्छा प्रस्ताव सुविधाओं का उपयोग करता है, यह नहीं करता है

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

यह सामान्य के लिए उबला हुआ है: बस कारण, हिम्मत मत करो

व्यक्तिगत रूप से मुझे ठोस या ऊप की परवाह नहीं है, मैं इसे बहुत समय पहले बढ़ा दिया था, आपने इसे "uberclass antipattern" तर्क फेंक कर लाया और फिर "इसकी व्याख्या के लिए स्वतंत्रता की एक डिग्री" का समर्थन किया।

इस पूरी चर्चा में उल्लिखित एकमात्र व्यावहारिक कारण यह है: https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -308362119

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

और कुछ पोस्ट एक जैसे https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -345496014

लेकिन यह (new (...) => MyClass) & MyStaticInterface . द्वारा कवर किया गया है

यह सटीक उपयोग का मामला है और एक कारण है कि मैं यहां हूं। क्या आप वोटों की संख्या देखते हैं? आपको क्यों लगता है कि practical क्या है और क्या नहीं, यह तय करना व्यक्तिगत रूप से आप पर निर्भर है? Practical वह है जिसे practice में रखा जा सकता है, और (लिखने के क्षण में) 83 लोगों को यह सुविधा बहुत व्यावहारिक लगेगी। कृपया दूसरों का सम्मान करें और वाक्यांशों को संदर्भ से बाहर निकालने और विभिन्न buzzwords प्रदर्शित करने से पहले पूरा धागा पढ़ें। आपने जो कुछ भी पार किया था, वह निश्चित रूप से आपका अहंकार नहीं है।

यह सामान्य ज्ञान है कि व्यावहारिक चीजें वे हैं जो समस्याओं को हल करती हैं, गैर-व्यावहारिक चीजें वे हैं जो आपकी सुंदरता की भावना को झुकाती हैं, मैं दूसरों का सम्मान करता हूं लेकिन इस सवाल का सम्मान करता हूं (अब ज्यादातर बयानबाजी) अभी भी रखती है: यह प्रस्ताव किस समस्या का इरादा रखता है https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -308362119 और https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -289084844 के लिए दिए गए (new (...) => MyClass) & MyStaticInterface को हल करें

कृपया उत्तर न दें

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

इसके अलावा, हमने अभी भी अमूर्त वर्गों को संबोधित नहीं किया है?

मेरी राय में, अमूर्त वर्गों का उपयोग न करने का समाधान समाधान नहीं है। यह एक कामकाज है! एक कामकाज क्या आसपास?

मुझे लगता है कि यह सुविधा अनुरोध मौजूद है क्योंकि अनुरोधकर्ता सहित कई लोगों ने पाया है कि इंटरफेस में abstract static या static जैसी अपेक्षित सुविधा मौजूद नहीं थी।

पेश किए गए समाधान के आधार पर, क्या static कीवर्ड को भी मौजूद होने की आवश्यकता है यदि इसके 'उपयोग से बचने के लिए कोई वैकल्पिक समाधान है? मुझे लगता है कि यह सुझाव देना भी उतना ही हास्यास्पद होगा।

यहां समस्या यह है कि static बहुत अधिक समझ में आता है।
उत्पन्न रुचि के आधार पर, क्या हम कुछ कम खारिज करने वाली चर्चा कर सकते हैं?

क्या इस प्रस्ताव पर कोई अद्यतन किया गया है? विचार करने लायक कोई भी तर्क प्रदर्शित करता है कि हमारे पास static abstract और इसी तरह क्यों नहीं होना चाहिए?
क्या हमारे पास और सुझाव हो सकते हैं जो बताते हैं कि यह उपयोगी क्यों होगा?

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

जैसा कि मैं समझता हूँ दो प्रस्ताव हैं:

1. इंटरफेस और प्रकार स्थिर गुणों और विधियों को परिभाषित कर सकते हैं

interface ISerializable<T> { 
   static fromJson(json: string): T;
}

1. अमूर्त वर्ग अमूर्त स्थैतिक विधियों को परिभाषित कर सकते हैं

abstract class MyClass<T> implements ISerializable<T> {
   abstract static fromJson(json: string): T;
}

class MyOtherClass extends MyClass<any> {
  static fromJson(json: string) {
  // unique implementation
  }
}

प्रस्ताव एक के लिए, तकनीकी रूप से एक कामकाज है! जो महान नहीं है, लेकिन वह कम से कम कुछ है। लेकिन यह एक कामकाज है।

आप अपने इंटरफेस को दो भागों में विभाजित कर सकते हैं और अपनी कक्षा को फिर से लिख सकते हैं जैसे

interface StaticInterface {
  new(...args) => MyClass;
  fromJson(json): MyClass;
}

interface InstanceInterface {
  toJson(): string;
}

const MyClass: StaticInterface = class implements InstanceInterface {
   ...
}

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

लेकिन फिर, प्रस्ताव 2 के बारे में क्या? इसके बारे में कुछ भी नहीं किया जा सकता है, है ना? मुझे लगता है कि यह भी संबोधित करने योग्य है!

इनमें से किसी एक प्रकार का व्यावहारिक उपयोग क्या है—इनमें से किसी एक का उपयोग कैसे किया जाएगा?

interface JsonSerializable {
    toJSON(): string;
    static fromJSON(serializedValue: string): JsonSerializable;
}

यह कहना पहले से ही संभव है कि कोई मान { fromJSON(serializedValue: string): JsonSerializable; } जैसी वस्तु होना चाहिए, तो क्या यह सिर्फ एक पैटर्न को लागू करने के लिए चाहता है? मुझे एक प्रकार की जाँच के दृष्टिकोण से इसका लाभ नहीं दिख रहा है। एक साइड नोट के रूप में: इस मामले में यह एक ऐसे पैटर्न को लागू कर रहा होगा जिसके साथ काम करना मुश्किल है- क्रमांकन प्रक्रिया को अलग-अलग धारावाहिक वर्गों या कार्यों में स्थानांतरित करना बेहतर होगा, कई कारणों से मैं यहां नहीं पहुंचूंगा।

साथ ही, ऐसा कुछ क्यों किया जा रहा है?

class FirstChildClass extends AbstractParentClass {
    public static getSomeClassDependentValue(): string {
        return 'Some class-dependent value of class FirstChildClass';
    }
}

इसके बजाय या तो टेम्पलेट विधि या रणनीति पैटर्न का उपयोग करने के बारे में क्या? यह काम करेगा और अधिक लचीला होगा, है ना?

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

स्थिर प्रतिक्रिया विधियों के लिए एक वैध उपयोगकेस है, जो इसके बारे में है

@ एलेक्सी-बायकोव आह, ठीक है। उन मामलों के लिए यह बेहतर हो सकता है कि constructor संपत्ति पर एक प्रकार जोड़ने से उस दुर्लभ परिदृश्य में टाइप चेकिंग होगी। उदाहरण के लिए:

interface Component {
    constructor: ComponentConstructor;
}

interface ComponentConstructor {
    displayName?: string;
}

class MyComponent implements Component {
    static displayName = 5; // error
}

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

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

मेरे पास एक समान विचार था: https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -437071092

क्या धारावाहिक/deserialize पैटर्न अपथ्रेड वर्णित "वैध" नहीं है?

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

मान लीजिए मेरे पास एक पुस्तकालय है जो स्थिर foo(x: number, y: boolean, z: string) विधि के साथ भाई वर्गों का एक सेट प्रदान करता है, और उम्मीद यह है कि उपयोगकर्ता एक फैक्ट्री क्लास लिखेंगे जो इनमें से कई कक्षाएं लेता है और उदाहरण बनाने के लिए विधि को कॉल करता है। (हो सकता है कि यह deserialize या clone या unpack या loadFromServer हो, कोई फर्क नहीं पड़ता।) उपयोगकर्ता समान (संभवतः सार) माता-पिता के उपवर्ग भी बनाता है पुस्तकालय से कक्षा।

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

मैं गारंटी देना चाहता हूं कि जो उपयोगकर्ता नए पुस्तकालय संस्करण में अपडेट करते हैं, वे संकलन-समय पर ब्रेकिंग परिवर्तनों को पकड़ लेंगे। पुस्तकालय को उपरोक्त स्थिर इंटरफ़ेस वर्कअराउंड में से एक को निर्यात करना है (जैसे type MyClass = (new (data: number[]) => MyInterface) & MyStaticInterface; ) और आशा है कि उपभोक्ता ने इसे सभी सही स्थानों पर लागू किया है। यदि वे अपने कार्यान्वयन में से एक को सजाने के लिए भूल गए हैं या यदि उन्होंने अपने कारखाने वर्ग में foo के कॉल हस्ताक्षर का वर्णन करने के लिए निर्यात किए गए पुस्तकालय का उपयोग नहीं किया है, तो संकलक कुछ भी नहीं बदल सकता है और उन्हें रनटाइम त्रुटियां मिलती हैं . तुलना करें कि मूल वर्ग में abstract static विधियों के एक समझदार कार्यान्वयन के साथ - कोई विशेष एनोटेशन की आवश्यकता नहीं है, उपभोग करने वाले कोड पर कोई बोझ नहीं है, यह सिर्फ बॉक्स से बाहर काम करता है।

@ thw0rted क्या अधिकांश पुस्तकालयों को इन वर्गों के किसी प्रकार के पंजीकरण की आवश्यकता नहीं होगी और उस बिंदु पर टाइप जांच हो सकती है? उदाहरण के लिए:

// in the library code...
class SomeLibraryContext {
    register(classCtor: Function & { deserialize(serializedString: string): Component; }) {
        // etc...
    }
}

// then in the user's code
class MyComponent extends Comonent {
    static deserialize(serializedString: string) {
        return JSON.parse(serializedString) as Component;
    }
}

const context = new SomeLibraryContext();
// type checking occurs here today. This ensures `MyComponent` has a static deserialize method
context.register(MyComponent);

या इन वर्गों के उदाहरण पुस्तकालय के साथ उपयोग किए जा रहे हैं और पुस्तकालय स्थिर तरीकों को प्राप्त करने के लिए उदाहरण से निर्माता के पास जाता है? यदि ऐसा है, तो पुस्तकालय के डिजाइन को स्थिर तरीकों की आवश्यकता नहीं होने के लिए बदलना संभव है।

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

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

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

किसी बिंदु पर, मैंने इसे shortName और longName दोनों की आवश्यकता के लिए बदल दिया (उपलब्ध स्क्रीन स्पेस की विभिन्न मात्राओं के साथ विभिन्न संदर्भों में प्रदर्शित होने के लिए)। abstract static name: string; को abstract static shortName: string; आदि में बदलने के लिए providerList: Type<Provider> & { shortName: string } & { longName: string } के लिए पिक-लिस्ट घटक को बदलने के बजाय यह अधिक सरल होता। यह इरादे को सही जगह पर (अर्थात अमूर्त माता-पिता में, उपभोग करने वाले घटक में नहीं) बताता है, और पढ़ने में आसान और बदलने में आसान है। मुझे लगता है कि हम कह सकते हैं कि एक समाधान है, लेकिन मुझे अभी भी विश्वास है कि यह प्रस्तावित परिवर्तनों की तुलना में निष्पक्ष रूप से बदतर है।

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

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

उत्तर के लिए धन्यवाद।

@ग्रीनी https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -449610196

@greeny यहाँ एक कार्यशील समाधान है: https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -437071092

विशेष रूप से इसका यह हिस्सा:

type MyClass = (new (text: string) => MyInterface) & { myStaticMethod(): string; }

एक और उपयोग-मामला: जेनरेट कोड/आंशिक वर्ग शिम्स

• मैं @rsuter/nswag लाइब्रेरी का उपयोग कर रहा हूं, जो स्वैगर विनिर्देशों को उत्पन्न करता है।
• आप एक 'एक्सटेंशन' फ़ाइल लिख सकते हैं जो जेनरेट की गई फ़ाइल में विलय हो जाती है।
• एक्सटेंशन फ़ाइल कभी नहीं चलती है, लेकिन इसे स्वयं संकलित करने की आवश्यकता होती है!
• कभी-कभी उस फ़ाइल के भीतर मुझे किसी ऐसी चीज़ को संदर्भित करने की आवश्यकता होती है जो अभी तक मौजूद नहीं है (क्योंकि यह उत्पन्न हुई है)
• इसलिए मैं इसके लिए एक शिम/इंटरफ़ेस इस प्रकार घोषित करना चाहता हूं
• नोट: आप निर्दिष्ट कर सकते हैं कि अंतिम विलय में कुछ निश्चित import कथनों को अनदेखा कर दिया गया है, इसलिए अंतिम जेनरेट कोड में 'shim' शामिल को अनदेखा कर दिया गया है।

interface SwaggerException
{
    static isSwaggerException(obj: any): obj is SwaggerException;
}

लेकिन मैं ऐसा नहीं कर सकता, और वास्तव में एक वर्ग लिखना है - जो ठीक है लेकिन फिर भी गलत लगता है। मैं बस चाहता हूं - जैसा कि कई अन्य लोगों ने कहा है - 'यह अनुबंध है' कहने के लिए

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

इसके अलावा, मैं वास्तव में क्लीनर d.ts फाइलें देखना चाहता हूं - इस सुविधा और उन फाइलों के साथ कुछ ओवरलैप होना चाहिए। JQueryStatic जैसे कुछ को समझना मुश्किल है क्योंकि ऐसा लगता है कि यह सिर्फ एक हैक है। इसके अलावा वास्तविकता यह है कि d.ts फाइलें अक्सर पुरानी हो जाती हैं और उनका रखरखाव नहीं किया जाता है और आपको खुद को शिम घोषित करने की आवश्यकता होती है।

(jQuery का उल्लेख करने के लिए खेद है)

क्रमबद्धता मामले के लिए मैंने ऐसा कुछ किया।

export abstract class World {

    protected constructor(json?: object) {
        if (json) {
            this.parseJson(json);
        }
    }

    /**
     * Apply data from a plain object to world. For example from a network request.
     * <strong i="6">@param</strong> json Parsed json object
     */
    abstract parseJson(json: object): void;

    /**
     * Parse instance to plane object. For example to send it through network.
     */
    abstract toJson(): object;
}

लेकिन ऐसा कुछ उपयोग करना अभी भी आसान होगा:

export abstract class World {

    /**
     * Create a world from plain object. For example from a network request.
     * <strong i="10">@param</strong> json Parsed json object
     */
    abstract static fromJson(json: object): World;

    /**
     * Parse instance to plane object. For example to send it through network.
     */
    abstract toJson(): object;
}

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

यह मुद्दा दो साल खुला है और इसमें 79 टिप्पणियाँ हैं। इसे Awaiting More Feedback के रूप में लेबल किया गया है। क्या आप बता सकते हैं कि निर्णय लेने के लिए आपको और क्या प्रतिक्रिया चाहिए?

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

उदाहरण के लिए, अगला.js पेज बनाने से पहले पेज प्रॉपर्टी पाने के लिए एक स्थिर getInitialProps फ़ंक्शन का उपयोग करता है। यदि यह फेंकता है, तो पृष्ठ का निर्माण नहीं होता है, बल्कि त्रुटि पृष्ठ होता है।

https://github.com/zeit/next.js/blob/master/packages/next/README.md#fetching -data-and-component-lifecycle

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

मुझे लगता है कि यह मुद्दा यहां इतने लंबे समय से मौजूद है क्योंकि जावास्क्रिप्ट स्वयं स्थिर चीज़ में अच्छा नहीं है 🤔

स्टेटिक इनहेरिटेंस पहले स्थान पर कभी मौजूद नहीं होना चाहिए। मैं

कौन स्टैटिक मेथड को कॉल करना चाहता है या स्टैटिक फील्ड को पढ़ना चाहता है? मैं

• बाल वर्ग: यह स्थिर नहीं होना चाहिए
• मूल वर्ग: कंस्ट्रक्टर तर्क का उपयोग करें
• अन्य: ISomeClassConstructor इंटरफ़ेस का उपयोग करें

क्या कोई अन्य उपयोग मामला है?🤔🤔🤔🤔

इस पर कोई अपडेट बिल्कुल?

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

डेकोरेटर को इस प्रकार परिभाषित किया गया है:

export const statics = <T extends new (...args: Array<unknown>) => void>(): ((c: T) => void) => (_ctor: T): void => {};

अगर मेरे पास स्थिर कंस्ट्रक्टर सदस्य इंटरफ़ेस है जिसे परिभाषित किया गया है

interface MyStaticType {
  new (urn: string): MyAbstractClass;
  isMember: boolean;
}

और उस वर्ग पर लागू किया गया है जिसे सदस्यों को T पर स्थिर रूप से घोषित करना चाहिए:

@statics<MyStaticType>()
class MyClassWithStaticMembers extends MyAbstractClass {
  static isMember: boolean = true;
  // ...
}

सबसे लगातार उदाहरण अच्छा है:

interface JsonSerializable {
    toJSON(): string;
    static fromJSON(serializedValue: string): JsonSerializable;
}

लेकिन जैसा कि यहां #13462 में कहा गया है:

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

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

इसलिए मैं इसके सभी दोषों के साथ निम्नलिखित का प्रस्ताव कर सकता हूं:

एक इंटरफ़ेस या तो किसी ऑब्जेक्ट या क्लास का वर्णन कर सकता है। मान लें कि class_interface कीवर्ड के साथ एक क्लास इंटरफ़ेस नोट किया गया है।

class_interface ISerDes {
    serialize(): string;
    static deserialize(str: string): ISerDes
}

क्लास (और क्लास इंटरफेस) किसी ऑब्जेक्ट इंटरफेस का उपयोग करके अपने स्थिर प्रतीकों को घोषित करने के लिए statically implements कीवर्ड का उपयोग कर सकते हैं ( क्लास इंटरफेस statically लागू नहीं किया जा सकता है)।

क्लास (और क्लास इंटरफेस) अभी भी किसी ऑब्जेक्ट इंटरफेस या क्लास इंटरफेस के साथ implements कीवर्ड का उपयोग करेंगे।

एक वर्ग इंटरफ़ेस तब स्थिर रूप से कार्यान्वित ऑब्जेक्ट इंटरफ़ेस और एक इंस्टेंस कार्यान्वित इंटरफ़ेस के बीच मिश्रण कर सकता है। इस प्रकार, हम निम्नलिखित प्राप्त कर सकते हैं:

interface ISerializable{
    serialize(): string;
}
interface IDeserializable{
    deserialize(str: string): ISerializable
}

class_interface ISerDes implements ISerializable statically implements IDeserializable {}

इस तरह, इंटरफेस अपना अर्थ रख सकते हैं, और class_interface कक्षाओं की परिभाषाओं के लिए समर्पित एक नए प्रकार का अमूर्त प्रतीक होगा।

एक छोटा गैर-महत्वपूर्ण उपयोग-मामला अधिक:
एओटी संकलन के लिए कोणीय में, आप डेकोरेटर्स में फ़ंक्शन को कॉल नहीं कर सकते (जैसे @NgModule मॉड्यूल डेकोरेटर में)
कोणीय मुद्दा

सेवा कार्यकर्ता मॉड्यूल के लिए, आपको इस तरह की चीज़ चाहिए:
ServiceWorkerModule.register('ngsw-worker.js', {enabled: environment.production})
उपवर्गों का उपयोग करते हुए हमारा पर्यावरण, अमूर्त वर्ग को लागू करने के लिए डिफ़ॉल्ट मानों और अमूर्त गुणों के साथ विस्तारित करता है। समान कार्यान्वयन उदाहरण
तो एओटी काम नहीं करता है क्योंकि एक वर्ग का निर्माण एक कार्य है, और त्रुटि फेंकता है जैसे: Function calls are not supported in decorators but ..

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

इंटरफ़ेस के साथ इस तरह से काम कर सकता है:

// default.env.ts
interface ImplementThis {
  static propToImplement: boolean;
}

class DefaultEnv {
  public static production: boolean = false;
}

// my.env.ts
class Env extends DefaultEnv implements ImplementThis {
  public static propToImplement: true;
}

export const environment = Env;

अमूर्त सांख्यिकी के साथ इस तरह से काम कर सकता है:

// default.env.ts
export abstract class AbstractDefaultEnv {
  public static production: boolean = false;
  public abstract static propToImplement: boolean;
}
// my.env.ts
class Env extends AbstractDefaultEnv {
  public static propToImplement: true;
}

export const environment = Env;

वर्कअराउंड हैं, लेकिन वे सभी कमजोर हैं: /

@DanielRosenwasser @RyanCavanaugh उल्लेखों के लिए क्षमा चाहते हैं, लेकिन ऐसा लगता है कि यह सुविधा सुझाव - जिसे समुदाय से बहुत समर्थन प्राप्त है, और मुझे लगता है कि इसे लागू करना काफी आसान होगा - मुद्दों की श्रेणी में गहराई से दफन हो गया है। क्या आप में से किसी के पास इस सुविधा के बारे में कोई टिप्पणी है, और क्या किसी जनसंपर्क का स्वागत किया जाएगा?

क्या यह समस्या #1263 का डुप्लीकेट नहीं है? मैं

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

मुझे लगता है कि इंटरफेस में स्थिर तरीके अमूर्त वर्गों पर स्थिर सार विधियों के रूप में सहज ज्ञान युक्त नहीं हैं।

मुझे लगता है कि इंटरफेस में स्थिर तरीकों को जोड़ना थोड़ा स्केची है क्योंकि एक इंटरफ़ेस को किसी ऑब्जेक्ट को परिभाषित करना चाहिए, क्लास नहीं। दूसरी ओर, एक अमूर्त वर्ग को निश्चित रूप से स्थिर अमूर्त विधियों की अनुमति दी जानी चाहिए, क्योंकि उपवर्गों को परिभाषित करने के लिए अमूर्त वर्गों का उपयोग किया जाता है। जहां तक ​​​​इसका कार्यान्वयन जाता है, इसे केवल अमूर्त वर्ग (जैसे class extends MyAbstractClass ) का विस्तार करते समय टाइप-चेक करने की आवश्यकता होगी, न कि इसे एक प्रकार के रूप में उपयोग करते समय (उदाहरण के लिए let myInstance: MyAbstractClass )।

उदाहरण:

abstract class MyAbstractClass {
  static abstract bar(): number;
}

class Foo extends MyAbstractClass {
  static bar() {
    return 42;
  }
}

अभी आवश्यकता से बाहर मैं इसका उपयोग करता हूं

abstract class MultiWalletInterface {

  static getInstance() {} // can't write a return type MultiWalletInterface

  static deleteInstance() {}

  /**
   * Returns new random  12 words mnemonic seed phrase
   */
  static generateMnemonic(): string {
    return generateMnemonic();
  }
}

यह असुविधाजनक है!

मैं एक समस्या के साथ आया था जहाँ मैं "ऑब्जेक्ट" में गुण जोड़ रहा हूँ, यहाँ एक सैंडबॉक्स उदाहरण है

interface Object {
    getInstanceId: (object: any) => number;
}

Object.getInstanceId = () => 42;
const someObject = {};
Object.getInstanceId(someObject); // correct
someObject.getInstanceId({}); // should raise an error but does not

किसी भी ऑब्जेक्ट इंस्टेंस को अब संपत्ति getInstanceId माना जाता है जबकि केवल Object होना चाहिए। एक स्थिर संपत्ति के साथ, समस्या हल हो गई होगी।

आप ऑब्जेक्ट कंस्ट्रक्टर को बढ़ाना चाहते हैं, ऑब्जेक्ट को नहीं। आप एक इंस्टेंस विधि घोषित कर रहे हैं, जब आप वास्तव में कन्स्ट्रक्टर को एक विधि संलग्न करना चाहते हैं। मुझे लगता है कि घोषणा विलय के माध्यम से यह पहले से ही संभव है:

```` टीएस
वैश्विक घोषित करें {
इंटरफ़ेस ऑब्जेक्ट कंस्ट्रक्टर {
हैलो (): स्ट्रिंग;
}
}

ऑब्जेक्ट.हैलो ();
````

@thw0rted बहुत बढ़िया! धन्यवाद, मुझे ऑब्जेक्ट कंस्ट्रक्टर के बारे में पता नहीं था

बड़ा मुद्दा यह है कि आप इंस्टेंस-प्रकार के बजाय कन्स्ट्रक्टर-प्रकार को बढ़ा रहे हैं। मैंने अभी Object में lib.es5.d.ts $ घोषणा को देखा और पाया कि यह ObjectConstructor प्रकार का है।

मेरे लिए यह विश्वास करना कठिन है कि यह मुद्दा अभी भी आसपास है। यह कई वास्तविक उपयोग के मामलों के साथ एक वैध रूप से उपयोगी सुविधा है।

टाइपस्क्रिप्ट का पूरा बिंदु हमारे कोडबेस में टाइप सुरक्षा सुनिश्चित करने में सक्षम होना है, इसलिए, दो साल के फीडबैक के बाद भी यह सुविधा "फीडबैक के लिए लंबित" क्यों है?

मैं इस पर रास्ता बंद कर सकता हूं, लेकिन क्या पाइथन के मेटाक्लास जैसे कुछ इस समस्या को देशी, स्वीकृत तरीके से हल करने में सक्षम होंगे (यानी हैक या वर्कअराउंड नहीं) टाइपस्क्रिप्ट के प्रतिमान का उल्लंघन किए बिना (यानी उदाहरण के लिए अलग टाइपस्क्रिप्ट प्रकार रखते हुए और कक्षा)?

कुछ इस तरह:

interface DeserializingClass<T> {
    fromJson(serializedValue: string): T;
}

interface Serializable {
    toJson(): string;
}

class Foo implements Serializable metaclass DeserializingClass<Foo> {
    static fromJson(serializedValue: string): Foo {
        // ...
    }

    toJson(): string {
        // ...
    }
}

// And an example of how this might be used:
function saveObject(Serializable obj): void {
    const serialized: string = obj.toJson();
    writeToDatabase(serialized);
}

function retrieveObject<T metaclass DeserializingClass<T>>(): T {
    const serialized: string = getFromDatabase();
    return T.fromJson(serialized);
}

const foo: Foo = new Foo();
saveObject(foo);

const bar: Foo = retrieveObject<Foo>();

ईमानदारी से इस दृष्टिकोण का सबसे कठिन हिस्सा ऐसा लगता है जैसे यह एक सार्थक, टाइपस्क्रिप्ट-वाई कीवर्ड के साथ आ रहा होगा metaclass ... staticimplements , classimplements , withstatic , implementsstatic ... सुनिश्चित नहीं है।

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

आइए #34516 और #33892 पर चर्चा करें कि आप किस सुविधा के लिए जा रहे हैं