Typescript: सुझाव: एक्सेसर्स को विभिन्न प्रकार के प्राप्त/सेट करने की अनुमति दें

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

त्वरित उत्तर के लिए धन्यवाद, दान। मैं कम सुरुचिपूर्ण तरीके का पालन करूंगा। बहुत अच्छा कार्य करने के लिए धन्यवाद!

विभिन्न प्रकार के साथ एक जावास्क्रिप्ट गेटर और सेटर पूरी तरह से मान्य है और बहुत अच्छा काम करता है और मेरा मानना ​​​​है कि यह इस सुविधा का मुख्य लाभ/उद्देश्य है। टाइपस्क्रिप्ट को खुश करने के लिए केवल setMyDate() प्रदान करना इसे बर्बाद कर देता है।

शुद्ध जेएस पुस्तकालयों के बारे में भी सोचें जो इस पैटर्न का पालन करेंगे: .d.ts को एक संघ या any का खुलासा करना होगा।

समस्या यह है कि एक्सेसर्स .d.ts में सामान्य गुणों से भिन्न रूप से सामने नहीं आते हैं

तब यह सीमा तय की जानी चाहिए और यह मुद्दा खुला रहना चाहिए:

// MyClass.d.ts

// Instead of generating:
declare class MyClass {
  myDate: moment.Moment;
}

// Should generate:
declare class MyClass {
  get myDate(): moment.Moment;
  set myDate(value: Date | moment.Moment);
}

// Or shorter syntax:
declare class MyClass {
  myDate: (get: moment.Moment, set: Date | moment.Moment);
  // and 'fooBar: string' being a shorthand for 'fooBar: (get: string, set: string)'
}

मुझे एहसास है कि यह सिर्फ एक राय है, लेकिन एक सेटर लिखना जैसे कि a.x === y true के तुरंत बाद a.x = y; एक विशाल लाल झंडा नहीं है। उस तरह के पुस्तकालय के उपभोक्ता कैसे जानते हैं कि किन गुणों के जादुई दुष्प्रभाव हैं और कौन से नहीं?

कैसे [आप] जानते हैं कि किन गुणों के जादुई दुष्प्रभाव हैं और कौन से नहीं?

जावास्क्रिप्ट में यह सहज ज्ञान युक्त नहीं हो सकता है, टाइपस्क्रिप्ट में उपकरण (आईडीई + कंपाइलर) शिकायत करेंगे। हम टाइपस्क्रिप्ट को फिर से क्यों पसंद करते हैं? :)

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

यह तर्क दे रहा है कि जावास्क्रिप्ट कमजोर टाइप किया गया है, इसलिए टाइपस्क्रिप्ट को कमजोर टाइप किया जाना चाहिए। :-एस

यह तर्क दे रहा है कि जावास्क्रिप्ट कमजोर टाइप किया गया है, इसलिए टाइपस्क्रिप्ट को कमजोर टाइप किया जाना चाहिए

सी # इसकी अनुमति देता है और यह इस भाषा को कमजोर टाइप नहीं करता है सी # विभिन्न प्रकार के प्राप्त/सेट की अनुमति नहीं देता है।

सी # इसकी अनुमति देता है और यह इस भाषा को कमजोर टाइप नहीं करता है सी # विभिन्न प्रकार के प्राप्त/सेट की अनुमति नहीं देता है।

:आँख मारना:

कोई भी तर्क नहीं दे रहा है (जहां तक ​​​​मैं देख सकता हूं) कि एक्सेसर्स को कमजोर टाइप किया जाना चाहिए, वे तर्क दे रहे हैं कि हमारे पास प्रकार को परिभाषित करने की लचीलापन होनी चाहिए।

अक्सर एक सादे पुराने ऑब्जेक्ट को ऑब्जेक्ट इंस्टेंस के लिए कॉपी करने की आवश्यकता होती है।

    get fields(): Field[] {
      return this._fields;
    }

    set fields(value: any[]) {
      this._fields = value.map(Field.fromJson);
    }

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

@paulwalker जिस पैटर्न का आप वहां उपयोग करते हैं ( any लेने वाला एक सेटर और एक अधिक विशिष्ट प्रकार लौटने वाला गेटर) आज मान्य है।

@danquirk जानकर बहुत अच्छा लगा, धन्यवाद! ऐसा लगता है कि मुझे एसटी के लिए अपना आईडीई प्लगइन कंपाइलर अपडेट करने की जरूरत है।

@danquirk यह खेल के मैदान (या संस्करण 1.6.2) के अनुसार काम नहीं करता है:
http://www.typescriptlang.org/Playground#src =%0A%0Aclass%20Foo%20%7B%0A%0A%20%20get%20items()%3A%20string%5B%5D%20%7B%0A % 09% 20% 20 रिटर्न% 20% 5 बी% 5 डी% 3 बी% 0 ए% 20% 20% 7 डी% 0 ए% 20% 20% 0 ए% 20% 20 सेट% 20 आइटम (मूल्य% 3 ए% 20 कोई भी)% 20% 7 बी% 0 ए% 09% 20% 20% 0A% 20% 20% 7D% 0A% 7D

मैंने अभी टाइपस्क्रिप्ट @ अगला (संस्करण 1.8.0-देव.20151102) के साथ परीक्षण किया है, और इसमें एक त्रुटि भी है।

~$ tsc --version
message TS6029: Version 1.8.0-dev.20151102
~$ cat a.ts
class A {
    get something(): number {return 5;}
    set something(x: any) {}
}

~$ tsc -t es5 a.ts
a.ts(2,2): error TS2380: 'get' and 'set' accessor must have the same type.
a.ts(3,2): error TS2380: 'get' and 'set' accessor must have the same type.

विडंबना यह है कि मेरे उदात्त लिंटर को अपडेट करने के बाद, इसने अब कोई त्रुटि नहीं दी, जो टाइपस्क्रिप्ट 1.7.x का उपयोग कर रहा है। मैं मान रहा हूं कि यह 1.7+ में आगामी वृद्धि है, इसलिए शायद 1.8.0 वापस आ गया।

यहां तक ​​​​कि विजुअल स्टूडियो कोड (0.10.5 (दिसंबर 2015)) के संस्करण के साथ जो टाइपस्क्रिप्ट 1.7.5 का समर्थन करता है और टाइपस्क्रिप्ट 1.7.5 मेरी मशीन पर विश्व स्तर पर स्थापित है, यह अभी भी एक समस्या है:

तो यह किस संस्करण का समर्थन करेगा?
धन्यवाद

मुझे लगता है कि डैन गलत था। गेट्टर और सेटर समान प्रकार के होने चाहिए।

शर्म की बात है। प्रोटैक्टर परीक्षणों में उपयोग के लिए पेज ऑब्जेक्ट्स लिखते समय एक अच्छी सुविधा होती।

मैं एक चांदा परीक्षण लिखने में सक्षम होता:

po.email = "[email protected]";
expect(po.email).toBe("[email protected]");

... एक पृष्ठ वस्तु संलेखन द्वारा:

class PageObject {
    get email(): webdriver.promise.Promise<string> {
        return element(by.model("ctrl.user.email")).getAttribute("value")
    }
    set email(value: any) {
        element(by.model("ctrl.user.email")).clear().sendKeys(value);
    }
}

उस कोड के बारे में क्या सेटर को any प्रकार का होना आवश्यक है?

गेटटर एक webdriver.promise.Promise<string> लौटाएगा, फिर भी वह सेटर जिसे मैं string मान असाइन करना चाहता हूं।

हो सकता है कि चांदा परीक्षण का निम्नलिखित लंबा रूप इसे स्पष्ट करता है:

po.email = "[email protected]";
var currentEmail : webdriver.promise.Promise<string> = po.email;
expect(currentEmail).toBe("[email protected]")

@RyanCavanaugh अशक्त एनोटेशन की शुरुआत के साथ, यह कोड को रोकता है जो एक सेटर को कुछ डिफ़ॉल्ट मान पर सेट करने के लिए नल के साथ कॉल करने की अनुमति देता है।

class Style {
    private _width: number = 5;

    // `: number | null` encumbers callers with unnecessary `!`
    get width(): number {
        return this._width;
    }

    // `: number` prevents callers from passing in null
    set width(newWidth: number | null) {
        if (newWidth === null) {
            this._width = 5;
        }
        else {
            this._width = newWidth;
        }
    }
}

क्या आप कम से कम | null और | undefined की उपस्थिति में प्रकारों को भिन्न होने की अनुमति देने पर विचार कर सकते हैं?

यह वास्तव में एक अच्छी सुविधा होगी।

तो क्या यह एक विशेषता होगी?

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

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

मैं सहमत हूं।

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

जबकि मैं टाइपस्क्रिप्ट से प्यार करता हूं और टीम द्वारा इसमें किए गए सभी प्रयासों की सराहना करता हूं (वास्तव में, आप लोग रॉक!), मुझे यह स्वीकार करना होगा कि मैं इस निर्णय से निराश हूं। यह getFoo()/setFoo() या get foo()/set foo()/setFooEx() के विकल्पों की तुलना में बहुत बेहतर समाधान होगा।

समस्याओं की एक छोटी सूची:

• वर्तमान में हम मानते हैं कि गुण बिल्कुल एक प्रकार के होते हैं। अब हमें प्रत्येक स्थान में प्रत्येक संपत्ति के "पढ़ने" प्रकार और "लिखने" प्रकार के बीच अंतर करना होगा
• सभी प्रकार के संबंध काफी अधिक जटिल हो जाते हैं क्योंकि हमें एक के बजाय प्रति संपत्ति दो प्रकार का तर्क करना पड़ता है (क्या { get foo(): string | number; set foo(): boolean } { foo: boolean | string | number } को असाइन करने योग्य है, या इसके विपरीत?)
• वर्तमान में हम मानते हैं कि एक संपत्ति, सेट होने के बाद, अभी भी निम्न पंक्ति पर सेट मान का प्रकार है (जो स्पष्ट रूप से कुछ लोगों के कोडबेस में गलत धारणा है, वाट?) हमें शायद इस तरह के गुणों पर किसी भी प्रवाह नियंत्रण विश्लेषण को "बंद" करना होगा

ईमानदारी से, मैं वास्तव में कोड लिखने के तरीके के बारे में यहां निर्देशात्मक होने से बचने की कोशिश करता हूं, लेकिन मैं वास्तव में इस विचार पर आपत्ति करता हूं कि यह कोड

foo.bar = "hello";
console.log(foo.bar);

ऐसी भाषा में "hello" से अधिक कुछ भी मुद्रित करना चाहिए जो समझदार अर्थशास्त्र रखने का प्रयास करता है। गुणों में ऐसा व्यवहार होना चाहिए जो बाहरी पर्यवेक्षकों के लिए फ़ील्ड से अप्रभेद्य हो।

@RyanCavanaugh जबकि मैं इंजेक्शन राय पर आपके साथ सहमत हूं, मैं एक काउंटर तर्क देख सकता हूं कि _might_ बस बहुत टाइपस्क्रिप्टी हो ... एक सेटर पर कमजोर टाइप की गई कुछ फेंकना, लेकिन कुछ हमेशा दृढ़ता से टाइप किया गया, उदाहरण के लिए:

foo.bar = [ '1', 2 ];  // any[]
console.log(foo.bar);  // number[]: [ 1, 2 ]

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

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

उदाहरण के लिए एक रंग संपत्ति को Color उदाहरण के रूप में या CSS स्ट्रिंग के रूप में rgba(r, g, b, a) या 3 या 4 संख्याओं की एक सरणी के रूप में व्यक्त किया जा सकता है। संपत्ति को अभी भी Color के उदाहरण के रूप में टाइप किया गया है, क्योंकि यह वह प्रकार है जो आपको मूल्य पढ़ते समय मिलता है।

इसके बारे में कुछ जानकारी: https://developers.arcgis.com/javascript/latest/guide/autocasting/index.html

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

इस मुद्दे के लिए एक और उदाहरण: https://github.com/gulpjs/vinyl#filebase

file.base = 'd:\\dev';
console.log(file.base); //  'd:\\dev'
file.base = null;
console.log(file.base); //  'd:\\dev\\vinyl' (returns file.cwd)

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

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

class Memory {
    public location: string;
    public time: Date;
    public company: Person[];
}

class Person
{
    private _bestMemoryEver: Memory | null;

    public get bestMemoryEver(): Memory | null { // Might not have one yet
        return this._bestMemoryEver;
    }

    public set bestMemoryEver(memory: Memory) { // But when he/she gets one, it can only be replaced, not removed
        this._bestMemoryEver = memory;
    }
}

var someDude = new Person();
// ...
var bestMemory: Memory | null = someDude.bestMemoryEver;
//...
someDude.bestMemoryEver = null; // Oh no you don't!

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

@ हाथी-पोत दार्शनिक रूप से मुझे उदाहरण से बिल्कुल प्यार है, यह मनुष्यों की चंचल प्रकृति का अच्छी तरह से प्रतिनिधित्व करता है लेकिन मुझे विश्वास नहीं है कि यह null (या undefined की अनुमति देकर इसका बेहतर प्रतिनिधित्व नहीं करेगा। ) सेट किया जानेवाला। मैं सिस्टम में सिनैप्स विफलता को कैसे मॉडल कर सकता हूं?

@aluanhaddad आप synapse विफलता क्यों चाहते हैं? मैं अपने ब्रह्मांड में उस तरह की बुरी चीजें नहीं चाहता;)

इस पर कोई अपडेट? शून्य या अपरिभाषित पर सेट होने पर डिफ़ॉल्ट मान रखने के बारे में क्या?

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

नीचे वह है जो मैं प्राप्त करना चाहता हूं:

export class TestClass {
  private _prop?: number;

  get prop(): number {
    // return default value if not defined
    this._prop === undefined ? 0 : this._prop;
  }
  set prop(val: number | undefined) {
    this._prop = val;
  }
}

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

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

@mhegazy @kitsonk मैं पक्षपाती हो सकता हूं, लेकिन मुझे लगता है कि यह एक बग है जो एक सामान्य पैटर्न पर सख्त नल जांच के लिए पॉप अप करता है, खासतौर पर अन्य घुंघराले ब्रेस जैसे भाषाओं में जहां उनके पास अभी तक शून्य जांच नहीं है। वर्कअराउंड के लिए उपभोक्ता को बैंग ऑपरेटर का उपयोग करने की आवश्यकता होगी या यह जांचना होगा कि यह वास्तव में कभी भी शून्य नहीं है (जो कि डिफ़ॉल्ट मानों का उपयोग करने के साथ कभी भी शून्य नहीं होने का बिंदु है)।

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

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

https://github.com/Microsoft/TypeScript/issues/2521#issuecomment -199650959 के जवाब में
यहां एक प्रस्ताव डिजाइन है जिसे लागू करने के लिए कम जटिल होना चाहिए:

export interface Test {
  undefset prop1: number; // property [get] type number and [set] type number | undefined
  nullset prop2: number; // property [get] type number and [set] type number | null
  nilset prop3: number; // property [get] type number and [set] type number | null | undefined
  undefget prop4: number; // property [get] type number | undefined and [set] type number
  nullget prop5: number; // property [get] type number | null and [set] type number
  nilget prop6: number; // property [get] type number | null | undefined and [set] type number
}

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

क्या टाइपस्क्रिप्ट निहित निर्माणकर्ताओं का समर्थन कर सकता है? यही है, क्या मैं कह सकता हूं कि myThing.foo हमेशा एक Bar देता है, और इसे सीधे Bar सौंपा जा सकता है, लेकिन इसे number भी सौंपा जा सकता है डेवलपर की सुविधा के रूप में Bar को इनिशियलाइज़ करने के लिए चुपचाप लपेटा / उपयोग किया जाता है? यदि Bar की व्याख्या करके ऐसा करना संभव है, या शायद विशेष रूप से यह कहकर कि " number Bar<number> $ को असाइन करने योग्य है, तो यह सीज़ियम मुद्दे में चर्चा किए गए उपयोग के मामले को संबोधित करेगा, और इस सूत्र में उठाए गए कई मुद्दों को भी।

यदि नहीं, तो क्या मुझे एक अलग मुद्दे में निहित निर्माणकर्ता समर्थन का सुझाव देने की आवश्यकता है?

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

class MyThing{
  set foo(b: Bar<boolean> | boolean);
  get foo(): Bar<boolean>;
}

जो ऐसा लगता है जैसे @RyanCavanaugh सोचता है कि "समझदार शब्दार्थ" नहीं है।

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

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

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

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

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

बेहतर या बदतर के लिए जेएस ने हमें असाइनमेंट को फ़ंक्शन कॉल में बदलने की क्षमता दी है और लोग इसका उपयोग कर रहे हैं। set/get जोड़े को विभिन्न प्रकार निर्दिष्ट करने की क्षमता के बिना, परिवेश टाइपिंग में set/get भी क्यों है? साल्सा को यह जानने की जरूरत नहीं है कि एक संपत्ति को गेटटर और सेटर के साथ लागू किया जाता है यदि यह हमेशा myThing.foo को एक ही प्रकार के सदस्य चर के रूप में मानने वाला है, भले ही यह असाइनमेंट के किस तरफ हो। (जाहिर है, वास्तविक टाइपस्क्रिप्ट संकलन पूरी तरह से एक और बात है।)

@thw0rted

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

सी # के निहित उपयोगकर्ता परिभाषित रूपांतरण ऑपरेटर मूल्यों के प्रकार के आधार पर स्थिर कोड पीढ़ी करते हैं। टाइपस्क्रिप्ट प्रकार मिटा दिए जाते हैं और रनटाइम व्यवहार को प्रभावित नहीं करते हैं ( async / await किनारे के मामले Promise पॉलीफिलर्स को समझ में नहीं आते हैं)।

@kitsonk मुझे संपत्तियों के संबंध में सामान्य रूप से असहमत होना है। जावा, सी ++, और सी # के साथ उचित समय बिताने के बाद, मुझे बिल्कुल गुण पसंद हैं (जैसा कि सी # में देखा गया है) क्योंकि वे एक महत्वपूर्ण वाक्य रचनात्मक अमूर्तता प्रदान करते हैं (यह जावास्क्रिप्ट में कुछ हद तक सच है)। वे सिंटैक्स को बदले बिना सार्थक तरीकों से पढ़ने/लिखने की क्षमताओं को अलग करने के लिए इंटरफेस की अनुमति देते हैं। मुझे getX() जैसे तुच्छ कार्यों पर बर्बाद होने वाली क्रियाओं को देखने से नफरत है जब X प्राप्त करना निहित हो सकता है।
आईएमओ भ्रमित एपीआई, जिनमें से कई आप दुर्व्यवहार एक्सेसर्स कहते हैं, बहुत से _setters_ जादुई चीजें करते हैं।

अगर मेरे पास कुछ डेटा पर केवल पढ़ने के लिए, लेकिन लाइव दृश्य है, तो registry कहें, मुझे लगता है कि केवल पढ़ने योग्य गुणों को समझना बहुत आसान है।

interface Entry {key: string; value: any;}

export function createRegistry() {
  let entries: Entry[] = [];
  return {
    register(key: string, value: any) {
      entries = [...entries, {key, value}];
    },
    get entries() {
      return [...entries];
    }
  }
}

const registry = createRegistry();

registry.register('hello', '您好');
console.log(registry.entries); //[{key: 'hello', value: '您好'}]
registry.register('goodbye', '再见');
console.log(registry.entries); //[{key: 'hello', value: '您好'}, {key: 'goodbye', value: '再见'}]

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

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

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

जावास्क्रिप्ट प्रोजेक्ट को टाइपस्क्रिप्ट में पोर्ट करना। मैं इस समस्या से मिला ..

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

अद्यतन: यह मेरे लिए काम करता प्रतीत होता है

import { Component, Input } from '@angular/core';
import { flatMap, isString, isArray, isFalsy } from 'lodash';

@Component({
  selector: 'app-error-notification',
  templateUrl: './error-notification.component.html',
})

export class ErrorNotificationComponent {
  private _errors: Array<string> = [];
  constructor() { }
  /**
   * 'errors' is expected to be an input of either a string or an array of strings
   */
  @Input() set errors(errors: Array<string> | any){
      // Caller just passed in a string instead of an array of strings
      if (isString(errors)) {
        this._errors = [errors];
      }
      // Caller passed in array, assuming it is a string array
      if (isArray(errors)) {
        this._errors = errors;
      }
      // Caller passed in something falsy, which means we should clear error list
      if (isFalsy(errors)) {
        this._errors = [];
      }
      // At this point just set it to whatever might have been passed in and let
      // the user debug when it is broken.
      this._errors = errors;
  }

  get errors() {
    return this._errors;
  }
}

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

class Field {
  private _value: string;

  get value(): string {
    return this._value;
  }

  set value(value: any) {
    this._value = String(value);
  }
}

यह वही है जो 99% मूल कार्यान्वयन करता है (यदि आप किसी संख्या को (input as HTMLInputElement).value पर पास करते हैं तो यह हमेशा एक स्ट्रिंग लौटाएगा। वास्तव में प्राप्त करें और सेट को विधियों के रूप में माना जाना चाहिए और कुछ को अनुमति देनी चाहिए:

set value(value: string);
set value(value: number);
set value(value: any) {
  this._value = String(value);
}
  // AND/OR
set value(value: string | number) {
  this._value = String(value);
}

@raysuelzer , जब आप कहते हैं कि आपका कोड "काम करता है", तो ErrorNotificationComponent.errors एक प्रकार का Array<string> | any नहीं लौटाता है? इसका मतलब है कि हर बार जब आप इसका इस्तेमाल करते हैं तो आपको टाइप गार्ड की आवश्यकता होती है, जब आप जानते हैं कि यह वास्तव में केवल Array<string> लौटा सकता है।

@lifaon74 , जहां तक ​​मुझे पता है, इस मुद्दे पर कोई हलचल नहीं है। मुझे लगता है कि एक सम्मोहक मामला बनाया गया है - कई परिदृश्य प्रस्तुत किए गए हैं, कई विरासत जेएस कोड जिन्हें इस वजह से टाइपस्क्रिप्ट में ठीक से वर्णित नहीं किया जा सकता है - लेकिन मुद्दा बंद है। हो सकता है कि अगर आपको लगता है कि जमीनी तथ्य बदल गए हैं, तो एक नया खोलें? मैं पुराने तर्कों को फिर से पढ़ने पर टीम की नीति नहीं जानता, लेकिन मैं आपकी पीठ थपथपाऊंगा।

मैं पुराने तर्कों को फिर से पढ़ने पर टीम की नीति नहीं जानता, लेकिन मैं आपकी पीठ थपथपाऊंगा।

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

मेरी व्यक्तिगत भावना यह है कि यह एक _अच्छा होगा, विशेष रूप से मौजूदा जावास्क्रिप्ट कोड को मॉडल करने में सक्षम होने के लिए जो इस पैटर्न का प्रभावी ढंग से उपयोग करता है।

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

इस बात से सहमत। setter इतना सीमित होगा जब प्रकार समान होना चाहिए... कृपया सुधारें।

इसे पूरा करने के लिए सिफारिशों की तलाश है:

get price() {
    return (this._price as number);
  }

  set price(price) {
    this._price = typeof price === 'string' ? parseFloat(parseFloat(price).toFixed(8)) : parseFloat(price.toFixed(8));
  }

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

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

class Widget {
  get price(): number | /** <strong i="7">@impossible</strong> */ string | undefined { return this._price; }
  set price(val: number|string|undefined){ ... }
}

let w = new Widget();
w.price = 10;
// Annotation processes as "let p:number|undefined = (w.price as number|undefined)"
let p: number|undefined = w.price;

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

यह नहीं कह रहा कि यह सुविधा आवश्यक नहीं है, लेकिन यहां set के लिए बायपास करने का एक तरीका है। आईएमओ get हमेशा एक ही परिवर्तनीय प्रकार वापस करना चाहिए, इसलिए यह मेरे लिए काफी अच्छा था।

class Widget {
    get price(): number { return this._price; }
    set price(val){ return this.setPrice(val); } // call another function

    // do processing here
    private setPrice(price: number | string): number {
        let num = Number(price);
        return isNaN(num) ? 0 : num;
    }
}

@iamjoyce widget.price = '123' आपके कोड में संकलन त्रुटि का उत्सर्जन करता है

@iamjoyce => गलत है क्योंकि संकलक val: number में set price(val) मानता है

हाँ, मैं भी यहाँ हूँ क्योंकि कोणीय के घटकों के उपयोग से लगता है कि हम अलग-अलग गेटर/सेटर प्रकार चाहते हैं।

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

private _someProperty: SomeEnum;
set someProperty(value: SomeEnum | string) {
   this._someProperty = this.coerceSomeEnum(value);
} 
get someProperty(): SomeEnum {
  return this._someProperty;
}

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

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

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

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

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

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

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

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

एक वैकल्पिक सुझाव के रूप में, यदि उपयोगकर्ता परिभाषित प्रकार गार्ड को वापसी मूल्य पर लागू करने के लिए कुछ वाक्यविन्यास थे, तो यह भी पर्याप्त होगा। मुझे एहसास है कि यह सामान्य परिस्थितियों में, थोड़ा हास्यास्पद है, लेकिन वापसी मूल्य के साथ-साथ तर्कों पर उस तरह की अभिव्यक्ति होने से इन किनारे के मामलों को हल करने में मदद मिलेगी।

वापसी मूल्य पर उपयोगकर्ता परिभाषित प्रकार गार्ड, कुछ ऐसा होने का लाभ भी होता है जो किसी संपत्ति के लिए स्क्वैश होने पर प्रकार की घोषणा/इंटरफेस में व्यक्त हो सकता है?

यहां एक और उपयोग के मामले को जोड़ते हुए, mobx-state-tree कुछ अलग-अलग तरीकों से एक संपत्ति को सेट करने की अनुमति देता है (उदाहरणों और स्नैपशॉट प्रकारों से), हालांकि यह कभी भी इसे एक्सेसर प्राप्त करने से एक ही मानक तरीके (उदाहरणों) में वापस कर देगा, इसलिए यह अत्यंत उपयोगी होगा यदि यह समर्थित था।

मैं इस तरह के आसपास हो रहा हूँ:

interface SomeNestedString {
  foo: string;
}

...

private _foo: SomeNestedString | string;

get foo(): SomeNestedString | string {
  return this._foo;
}

set foo(value: SomeNestedString | string) {
  this._foo = (value as SomeNestedString).foo;
}

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

मैं TSLint के आसपास काम करने के लिए any का उपयोग कर रहा हूं। और संकलक या तो शिकायत नहीं करता है।

export class FooBar {
  private bar: string;

  get foo (): string | any {
    return this.bar;
  }

  set foo (value: Date | string | any) {
    // Type guarding enables IntelliSense in VS Code
    if (value instanceof Date) {
      this.bar = value.toISOString();
    } else if (typeof value === 'string') {
      this.bar = value;
    } else {
      this.bar = String(value); // Or throw an error
    }
  }
}

@jpidelatorre इस तरह आप टाइप सुरक्षा खो देते हैं।

const fooBar = new FooBar()
const a: number = fooBar.foo // works while it should fail
fooBar.foo = 123 // fails only at runtime, not compile time. It doesnt fail in this particular case with strings and numbers, but it will with something more complex

@keenondrums यही कारण है कि हम एक्सेसर्स के विभिन्न प्रकार चाहते हैं। मैंने जो पाया वह एक समाधान है, समाधान नहीं।

@jpidelatorre मेरा वर्तमान समाधान सेटर के रूप में किसी अन्य फ़ंक्शन का उपयोग करना है

export class FooBar {
  private bar: string;

  get foo (): string {
    return this.bar;
  }

  setFoo (value: Date | string ) {}
}

@keenondrums एक्सेसर्स की तरह दिखने में उतना अच्छा नहीं है, लेकिन अभी तक का सबसे अच्छा विकल्प है।

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

जो अभी बहुत बदसूरत है।

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

class Foo {
    get bar:()=>number;
    set bar:number;
}

const foo = new Foo();
foo.bar = 3;
foo.bar(); // 3

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

interface IFoo {
    bar: string;
}

class Foo implements IFoo {
    bar: string;
    toString():string;
}

class Example {
    get foo:Foo;
    set foo:Foo|IFoo;
}

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

क्या तथ्य यह है कि यह कोर डीओएम एपीआई का वर्णन करना असंभव बनाता है जो गणित को बिल्कुल बदलता है? @RyanCavanaugh कहते हैं

मैं वास्तव में इस विचार पर आपत्ति करता हूं कि इस कोड foo.bar = "hello"; console.log(foo.bar); को कभी भी "हैलो" से कुछ भी ऐसी भाषा में प्रिंट करना चाहिए जो समझदार अर्थशास्त्र रखने का प्रयास करता है।

हम इस बारे में बहस कर सकते हैं कि क्या इसे इस तरह इस्तेमाल किया जाना चाहिए , लेकिन डोम ने हमेशा el.hidden=1; console.log(el.hidden) // <-- true, not 1 जैसी संरचनाओं का समर्थन किया है। यह केवल एक पैटर्न नहीं है जिसका कुछ लोग उपयोग करते हैं, यह सिर्फ एक लोकप्रिय पुस्तकालय में नहीं है, इसलिए इसका समर्थन करना एक अच्छा विचार हो सकता है। यह एक मूल सिद्धांत है कि JS ने हमेशा कैसे काम किया है - DWIM का एक सा हिस्सा भाषा की आत्मा में बेक किया गया है - और भाषा के स्तर पर इसे असंभव बनाना TS के मूलभूत सिद्धांत को तोड़ता है, कि यह JS का "सुपरसेट" होना चाहिए। . यह एक बदसूरत बुलबुला है जो वेन आरेख से निकला है, और हमें इसे नहीं भूलना चाहिए।

यही कारण है कि मुझे अभी भी एक ही प्रकार के सेटर/गेटर रखने का विचार पसंद है:

number | boolean

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

वैकल्पिक रूप से, यह केवल निहित किया जा सकता है यदि गेटर पर इस्तेमाल किया जाने वाला प्रकार सेटर्स प्रकार का सख्त सबसेट था?

वैकल्पिक रूप से, यह केवल निहित किया जा सकता है यदि गेटर पर इस्तेमाल किया जाने वाला प्रकार सेटर्स प्रकार का सख्त सबसेट था?

!

मुझे लगता है कि हम सभी इस बात से सहमत हो सकते हैं कि आपको ऐसा प्रकार प्राप्त करने में सक्षम नहीं होना चाहिए जो व्यवस्थित नहीं था; मैं get पर टाइप को स्वचालित रूप से संकीर्ण करने का कोई तरीका चाहता हूं ताकि मैं जानता हूं कि यह हमेशा रहेगा।

मुझे समझ में नहीं आता कि क्यों कुछ आपत्ति कर रहे हैं कि यह टाइप सुरक्षा और सभी का उल्लंघन करेगा। मुझे नहीं लगता कि यह किसी भी प्रकार की सुरक्षा का उल्लंघन करता है यदि हम कम से कम सेटर को अलग-अलग प्रकार की अनुमति देते हैं, क्योंकि किसी भी तरह से हमारे पास एक चेक है कि आप किसी अन्य प्रकार को किसी संपत्ति पर सेट करने की अनुमति नहीं देंगे।
भूतपूर्व:
मान लें कि मेरे पास ऐरे के रूप में एक संपत्ति हैलेकिन डीबी से इसे कॉमा अलगाव के साथ एक स्ट्रिंग के रूप में वापस कर दिया जाएगा जैसे '10,20,40' कहें। लेकिन मैं इसे अभी मोड प्रॉपर्टी में मैप नहीं कर सकता, इसलिए यदि आप अनुमति दे सकते हैं तो यह बहुत मददगार होगा

निजी _कर्मचारी आईडी सूची: संख्या []

कर्मचारी आईडी सूची प्राप्त करें (): संख्या [] {
इसे वापस करें।_कर्मचारीIdList;
}
कर्मचारी आईडी सूची सेट करें (_idList: कोई भी ) {
अगर (टाइपऑफ़ _idList == 'स्ट्रिंग') {
this._employeeIdList = _idList.split(',').map(d => Number(d));
}
और अगर (टाइपऑफ़ _idList== 'ऑब्जेक्ट') {
this._employeeIdList = _idList संख्या के रूप में [];
}
}

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

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

हालांकि नाक को चालू करना और एक सेटर को परिभाषित करना अच्छा है जो एक प्रकार को आने वाले प्रकार के सबसेट के लिए मजबूर करता है और हमेशा उस सबसेट को कोड गंध के रूप में गेटटर में लौटाता है, वास्तव में, यह जेएस भूमि में एक सामान्य सामान्य पैटर्न है .

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

विश्वसनीय प्रकार DOM XSS से लड़ने के लिए एक नया ब्राउज़र API प्रस्ताव है। यह पहले से ही क्रोमियम (झंडे के पीछे) में लागू है। एपीआई का बड़ा हिस्सा विश्वसनीय प्रकारों को स्वीकार करने के लिए विभिन्न डीओएम गुणों के सेटर्स को संशोधित करता है। उदाहरण के लिए, .innerHTML TrustedHTML | string $ स्वीकार करता है जबकि यह हमेशा string लौटाता है। टाइपस्क्रिप्ट में एपीआई का वर्णन करने के लिए, हमें इस समस्या को ठीक करने की आवश्यकता होगी।

पिछली टिप्पणियों से अंतर यह है कि यह एक ब्राउज़र एपीआई है (और उपयोगकर्ता-भूमि पुस्तकालय नहीं) जिसे आसानी से बदला नहीं जा सकता है। साथ ही Element.innerHTML any बदलने का प्रभाव (जो वर्तमान में एकमात्र संभव समाधान है) उपयोगकर्ता-भूमि पुस्तकालय का सटीक वर्णन करने से बड़ा है।

क्या इस पुल-अनुरोध को फिर से खोलने की संभावना है? या क्या अन्य समाधान हैं जो मुझे याद आ रहे हैं?

सीसी: @mprobst , @koto।

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

@RyanCavanaugh तब भी जब गेटर और सेटर का एक ही प्रकार होता है, यह गारंटी नहीं है कि o.x === y के बाद o.x = y क्योंकि सेटर मूल्य को बचाने से पहले कुछ स्वच्छता कर सकता है।

element.scrollTop = -100;
element.scrollTop; // returns 0

मैं @vrana द्वारा दूसरी चिंता करता हूं। वर्तमान व्यवहार टाइपस्क्रिप्ट में कुछ मौजूदा एपीआई को मॉडल करना असंभव बनाता है।

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

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

आप उन एपीआई का प्रतिनिधित्व कर सकते हैं क्योंकि यह कहना सही है कि संपत्ति का प्रकार उन संभावित प्रकारों का संघ है जो आप सेटर को प्रदान कर सकते हैं या गेटटर से प्राप्त कर सकते हैं।

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

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

लेकिन यहां तक ​​​​कि एक पल के लिए इसे अलग करना, और उपयोगकर्ता एपीआई के बारे में बात करना, एक सेटर पर संघ प्रकारों को स्वीकार करने के लिए एक मजबूत उपयोग का मामला "स्क्रिप्टी" है। हम कई प्रकार के असतत प्रकारों को स्वीकार करना चाहते हैं जिन्हें हम स्वीकार्य रूप से उस प्रकार के लिए मजबूर कर सकते हैं जो हम वास्तव में चाहते हैं।

इसकी अनुमति क्यों दें? उपयोग में आसानी।

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

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

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

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

type urlRep = string | Url;

ज्यादातर चीजें बस इसके चारों ओर घूमती हैं, और केवल सामान्य प्रॉप्स से निपटती हैं, और कुछ मामलों में आप कुछ प्रकार के गार्ड के साथ ब्लैक बॉक्स को तोड़ देंगे।

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

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

और मुझे नहीं लगता कि कोई भी कभी भी सेटर/गेटर के लिए _disjoint_ प्रकार रखना चाहेगा। यहां जिस बात पर चर्चा की जा रही है, वह यह है कि एपीआई निर्माता एपीआई उपभोक्ता से कहता है कि गेटर एक प्रकार के साथ एक मूल्य लौटाएगा जो कि सेटर के संघ प्रकार का एक सख्त सबसेट है।

और मुझे नहीं लगता कि कोई भी कभी भी सेटर/गेटर के लिए अलग-अलग प्रकार के लिए चाहेगा।

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

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

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

उदाहरण के लिए, मेरे पास ऐसा कुछ है:

class Vector3 { /* ... */ }

type XYZ = Vector3 | [number, number, number] | {x: number, y: number, z: number}
type PropertyAnimator = (x: number, y: number, z: number, timestamp: number) => XYZ
type XYZSettables =  XYZ | PropertyAnimator

export class Transformable {
        // ...

        set position(newValue: XYZSettables) {
            this._setPropertyXYZ('position', newValue)
        }
        get position(): Vector3 {
            return this._props.position
        }

        // ...
}

और जैसा कि आप कल्पना कर सकते हैं, उपयोग बहुत लचीला है:

const transform = new Transformable

// use an array
transform.position = [20, 30, 40]

// use an object
transform.position = {y: 30, z: 40} // skip `x` this time

// animate manually, a property directly
requestAnimationFrame((time) => {
  transform.position.x = 100 * Math.sin(time * 0.001)
})

// animate manually, with an array, which could be shared across instances
const pos = [10, 20, 30]
requestAnimationFrame((time) => {
  pos[2] = 100 * Math.sin(time * 0.001)
  transform.position = pos
})

// Animate with a property function
transform.position = (x, y, z, time) => [x, y, 100 * Math.sin(time * 0.001)]

// or a simple increment:
transform.position = (x, y, z) => [x, y, ++z]

// etc

// etc

// etc

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

और मैं @kitsonk से पूरी तरह सहमत हूं:

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

टाइपस्क्रिप्ट 3.6 ने डिक्लेरेशन फाइल में एक्सेसर्स टाइप करने के लिए सिंटैक्स पेश किया , जबकि इस प्रतिबंध को बनाए रखा कि गेटर और सेटर का प्रकार समान होना चाहिए।

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

ऐसा लगता है कि @RyanCavanaugh ने 3 साल पहले इस सुविधा का सबसे ठोस खंडन किया था। मुझे आश्चर्य है कि हाल ही में रिपोर्ट किए गए डीओएम उपयोग-मामलों के साथ-साथ नई घोषणा वाक्यविन्यास की उपलब्धता एक नए निर्णय की अनुमति दे सकती है?

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

TSConf 2019 11 अक्टूबर को आयोजित किया जाएगा, यह सोचकर कि अगर किसी को मौका मिला तो यह प्रश्नोत्तर सत्र में एक महान पूर्वव्यापी समीक्षा होगी।

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

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

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

कम से कम, मुझे लगता है कि Design Limitation यहां हटाया जा सकता है, मुझे नहीं लगता कि यह अब और संबंधित है।

यह वास्तव में प्रॉक्सी करना भी मुश्किल बनाता है:
https://stackoverflow.com/questions/57948140/typescript-proxy-which-returns-a-different-type-from-get-than-it-takes-for-s

यह स्पष्ट रूप से इस तथ्य का कारण है कि प्रति #33749 .style.display = ...something nullable... अब टाइपचेक नहीं; जिसे एक शून्यता शुद्धता मुद्दे के रूप में प्रस्तुत किया गया है। यह थोड़ा बेतुका होना है ना? जब उन्हें बगफिक्स के रूप में गलत लेबल किया जाता है, तो नए ब्रेकिंग परिवर्तनों का पता लगाना कष्टप्रद होता है (मैं इसके कारण होने वाली वास्तविक समस्याओं की तलाश में गया था)। व्यक्तिगत रूप से, मुझे यह बहुत कम आश्चर्यजनक लगता है कि null में विशेष व्यवहार "डिफ़ॉल्ट का उपयोग करें" है, जो कि खाली स्ट्रिंग करता है; और टाइपस्क्रिप्ट 3.7 तक मैंने इसे कैप्चर करने के लिए नल का उपयोग करना पसंद किया। किसी भी मामले में, यह अच्छा होगा यदि जानबूझकर गलत प्रकार के एनोटेशन इस सीमा को हल करने के लिए किए गए थे, जिन्हें स्पष्ट रूप से इस तरह से लेबल किया गया था, ताकि समय को बचाने के लिए अपग्रेड मुद्दों को बचाया जा सके।

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

इसके लिए मेरा उपयोग मामला यह है कि मेरे पास एक एपीआई है जहां एक प्रॉक्सी एक वादा देता है, लेकिन एक सेट ऑपरेशन एक वादा नहीं करता है। मैं अभी टाइपस्क्रिप्ट में इसका वर्णन नहीं कर सकता।

let post = await loadPost()
let user = await loadUser()
post.author = user // Proxy handles links these two objects via remote IDs
await save(post)

// Somewhere else in code
let post = await loadPost()
let author = await post.author

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

उन्हें वास्तव में इस सूची से #6 और #7 को हटा देना चाहिए (https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals)

मेरा मुद्दा

मैं किसी आइटम को सेट विधि में किसी सरणी में धक्का देना चाहता हूं और प्राप्त विधि में संपूर्ण सरणी प्राप्त करना चाहता हूं। अभी के लिए मुझे set myArray(...value: string[]) का उपयोग करना होगा जो ठीक काम करता है। इस मुद्दे में बहुत उलझा हुआ है... कृपया इसे हटाने पर विचार करें। इसके लिए कोई सूचना या चेतावनी ठीक काम करेगी।

उदाहरण (मैं क्या करना चाहूंगा)

class MyClass {
   _myArray: string[] = [];

   set myArray(value: string) {
      this._myArray.push(value);
   }

   get myArray(): string[] {
      return this._myArray;
   }
}

उदाहरण (मुझे क्या करना है)

class MyClass {
   _myArray: string[] = [];

   set myArray(...value: string[]) {
      this._myArray.push(value[0]);
   }

   get myArray(): string[] {
      return this._myArray;
   }
}

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

मेरा उदाहरण

class TimeStorage {
    _startDate: string | Moment = ""
    _endDate: string | Moment = ""

    set startDate(date: Moment | string) {
        this._startDate = moment(date).utc()
    }
    get startDate(): Moment | string {
        return moment.utc(this._startDate)
    }

    set endDate(date: Moment) { 
        this._endDate = moment.utc(date)
    }
    get endDate() { 
        return moment.utc(this._endDate)
    }
}

मुझे पार्टी में थोड़ी देर हो गई है लेकिन मैंने हाल ही में इस मुद्दे पर खुद भाग लिया है। यह एक दिलचस्प दुविधा है इसलिए मैंने इसके साथ थोड़ा सा काम किया।

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

class Foo {
    constructor() {
        this._bar = '';
        this.baz = '';
    }

    // error: 'get' and 'set' accessor must have the same type.(2380)
    get bar(): string {
        return this._bar;
    }

    // error: 'get' and 'set' accessor must have the same type.(2380)
    set bar(value: string | number) {
        this._bar = value.toString();
    }

    public baz: string;
    private _bar: string;
}

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

/**
 * Abstract base class for properties.
 */
abstract class Property<GetType, SetType> {
    abstract get(): GetType;
    abstract set(value: SetType): void;
}

/**
 * Proxify an object so that it's get and set accessors are proxied to
 * the corresponding Property `get` and `set` calls.
 */
function proxify<T extends object>(obj: T) {
    return new Proxy<any>(obj, {
        get(target, key) {
            const prop = target[key];
            return (prop instanceof Property) ? prop.get() : prop;
        },
        set(target, key, value) {
            const prop = target[key];
            if (prop instanceof Property) {
                prop.set(value);
            } else {
                target[key] = value;
            }
            return true;
        }
    });
}

इस पुस्तकालय का उपयोग करके हम अपनी टाइप की गई संपत्ति को अपनी कक्षा के लिए इस तरह लागू कर सकते हैं:

class Bar extends Property<string, string | number> {
    constructor(bar: string | number) {
        super();
        this.set(bar);
    }

    get(): string {
        return this._bar;
    }

    set(value: string | number) {
        this._bar = value.toString();
    }

    private _bar: string;
}

class Foo {
    constructor() {
        this.bar = new Bar('');
        this.baz = '';
    }

    public bar: Bar;
    public baz: string;
}

और फिर, इस वर्ग का उपयोग करने के लिए bar के लिए सुरक्षित गेटर और सेटर टाइप करना होगा:

const foo = new Foo();

// use property's typed setter
foo.bar.set(42);
foo.baz = 'foobar';

// use property's typed getter
// output: 42 foobar
console.log(foo.bar.get(), foo.baz);

और यदि आपको संपत्ति सेटर्स या गेटर्स को अधिक गतिशील रूप से उपयोग करने की आवश्यकता है, तो आप इसे लपेटने के लिए proxify फ़ंक्शन का उपयोग कर सकते हैं:

const foo = new Foo();

// use proxified property setters
Object.assign(proxify(foo), { bar: 100, baz: 'hello world' });

// use property's typed getter
// output: 100 hello world
console.log(foo.bar.get(), foo.baz);

// use proxified property getters
// output: {"bar":"100","baz":"hello world"}
console.log(JSON.stringify(proxify(foo)));

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

बस कुछ अतिरिक्त नोट और फिर मैं वादा करता हूं कि मैं लोगों की इस लंबी सूची को स्पैम करना बंद कर दूंगा!

अगर हम इसे काल्पनिक पुस्तकालय में जोड़ते हैं:

/**
 * Create a property with custom `get` and `set` accessors.
 */
function property<GetType, SetType>(property: {
    get: () => GetType,
    set: (value: SetType) => void
}) {
    const obj = { ...property };
    Object.setPrototypeOf(obj, Property.prototype);
    return obj;
}

हमें एक कार्यान्वयन मिलता है जो मूल वर्ग के थोड़ा करीब है, और सबसे महत्वपूर्ण बात यह है कि this तक पहुंच है:

class Foo {
    constructor() {
        this._bar = '';
        this.baz = '';
    }

    public bar = property({
        get: (): string => {
            return this._bar;
        },
        set: (value: string | number) => {
            this._bar = value.toString();
        }
    });

    public baz: string;
    private _bar: string;
}

यह दुनिया की सबसे सुंदर चीज नहीं है लेकिन यह काम करती है। हो सकता है कि कोई इसे परिष्कृत कर सके और कुछ ऐसा बना सके जो वास्तव में अच्छा हो।

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

यहां मूल्य के प्रकार को बूलियन से बूलियन में बदलना आदर्श होगा|'', मूल्यों के सेट से मेल खाने के लिए जो वास्तव में सेटर द्वारा स्वीकार किए जाते हैं। टाइपस्क्रिप्ट के लिए आवश्यक है कि गेट्टर और सेटर दोनों का एक ही प्रकार हो, इसलिए यदि गेटर को एक बूलियन वापस करना चाहिए तो सेटर संकरा प्रकार के साथ फंस गया है ... कोणीय @Input() के लिए एक व्यापक, अधिक अनुमेय प्रकार की जाँच करने का समर्थन करता है। इनपुट फ़ील्ड के लिए ही घोषित किया गया। घटक वर्ग में ngAcceptInputType_ उपसर्ग के साथ एक स्थिर गुण जोड़कर इसे सक्षम करें:

````
क्लास सबमिट बटन {
निजी _अक्षम: बूलियन;

अक्षम हो जाओ (): बूलियन {
इसे वापस करें।_अक्षम;
}

अक्षम सेट करें (मान: बूलियन) {
this._disabled = (मान === '') || मूल्य;
}

स्थिर ngAcceptInputType_disabled: बूलियन|'';
}
````

कृपया, कृपया इसे ठीक करें।

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

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

इस बिंदु पर, मेरा मानना ​​​​है कि योगदानकर्ताओं पर यह संवाद करने की जिम्मेदारी है कि इस मुद्दे को फिर से क्यों नहीं खोला जा रहा है? क्या कोई ऐसा योगदान देने वाला सदस्य है जो इस समय इसके सख्त खिलाफ है?

हम NodeJs के लिए एक DOM लाइब्रेरी बना रहे हैं जो W3C स्पेक से मेल खाती है, लेकिन यह टाइपस्क्रिप्ट समस्या इसे असंभव बना देती है। किसी भी अद्यतन?

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

a) W3C DOM विनिर्देशन के कई हिस्सों को लागू करने का कोई अन्य तरीका नहीं है, जबकि b) टाइपस्क्रिप्ट के टाइप सिस्टम का उपयोग करना (जब तक कि आप सभी जगह any का उपयोग करने का सहारा नहीं लेते, जो टाइपस्क्रिप्ट के पूरे उद्देश्य को हरा देता है)।

typescriptlang.org का मुखपृष्ठ वर्तमान में गलत है जब यह बताता है:

टाइपस्क्रिप्ट जावास्क्रिप्ट का एक टाइप किया गया सुपरसेट है जो सादे जावास्क्रिप्ट को संकलित करता है।

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

इस सुविधा को लागू करने के संबंध में, मैं @ gmurray81 और कई अन्य लोगों से सहमत हूं जिन्होंने तर्क दिया है कि गेटर का प्रकार एक सेटर्स यूनियन प्रकार का सबसेट होना चाहिए। यह कोई असंबद्ध टाइपिंग सुनिश्चित नहीं करता है। यह दृष्टिकोण एक सेटर के कार्य को गेट्टर के प्रकार को नष्ट किए बिना इनपुट को साफ करने की अनुमति देता है (यानी, any का उपयोग करने के लिए मजबूर होना)।

यहाँ मैं क्या नहीं कर सकता। कुछ आसान है कि मैंने जेएस में ऐसा ही किया है लेकिन मैं टीएस में नहीं कर सकता।

4yo मुद्दा जिसे वास्तव में लागू किया जा सकता है।

export const enum Conns {
  none = 0, d = 1, u = 2, ud = 3,
  r = 4, rd = 5, ru = 6, rud = 7,
  l = 8, ld = 9, lu = 10, lud = 11,
  lr = 12, lrd = 13, lru = 14, lrud = 15,
  total = 16
}

class  Tile {
  public connections = Conns.none;

  get connLeft() { return this.connections & Conns.l; };

  set connLeft(val: boolean) { this.connections = val ? (this.connections | Conns.l) : (this.connections & ~Conns.l); }
}

अब इस मामले में चल रहा है। नीचे @calebjclark उद्धृत करने के लिए एक समझदार समाधान की तरह लगता है:

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

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

ऐसा कहा जा रहा है कि कक्षाएं पूरी तरह से इंटरफेस भी हैं, गेटर्स और सेटर्स अनिवार्य रूप से कार्यान्वयन विवरण हैं जो इंटरफ़ेस में प्रकट नहीं होंगे। ओपी के उदाहरण में, आप type MyClass = { myDate(): moment.Moment; } के साथ समाप्त होंगे। इंटरफ़ेस के हिस्से के रूप में आपको इन नए गेटर और सेटर प्रकारों को किसी भी तरह से बेनकाब करना होगा, हालांकि मैं व्यक्तिगत रूप से नहीं देखता कि यह वांछनीय क्यों होगा।

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

foo.x = y;
if (foo.x === y) { // this could be false?

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

@MikeyBurkman

[...] लेकिन अधिकांश मामलों में जहां आप टीएस (इस धागे में उदाहरणों सहित) का उपयोग करेंगे, मैं तर्क दूंगा कि ऑपरेटर ओवरलोडिंग की आवश्यकता शायद एक कोड गंध है [...]

 foo.x = y; 
 if (foo.x === y) { // this could be false?

इसलिए, केवल प्रकार मिलान होने से आश्चर्यजनक व्यवहार नहीं रोका जा सकता है, और वास्तव में el.style.display = ''; //so is this now true: el.style.display === ''? से पता चलता है कि यह सैद्धांतिक भी नहीं है। सादे पुराने क्षेत्रों के साथ भी, धारणा NaN के लिए नहीं है, वैसे।

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

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

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

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

एक आदर्श दुनिया में TS सभी JS API के साथ इंटरऑप करेगा। लेकिन ऐसा नहीं है। JS मुहावरों का एक समूह है जिसे TS में सही ढंग से टाइप नहीं किया जा सकता है। हालांकि, मैं चाहता हूं कि वे उन चीजों को ठीक करने पर ध्यान केंद्रित करें जो वास्तव में बेहतर प्रोग्रामिंग मुहावरों की ओर ले जाती हैं, बदतर नहीं। जबकि इसका एक उचित तरीके से समर्थन करना अच्छा होगा, एक दर्जन अन्य चीजें हैं जो मैं व्यक्तिगत रूप से चाहूंगा कि वे अपना सीमित समय पहले बिताएं। यह उस सूची में बहुत नीचे है।

@MikeyBurkman प्राथमिकता का प्रश्न मान्य है। मेरी प्राथमिक चिंता @RyanCavanaugh के इस मुद्दे को बंद करने और इसे लिखने का निर्णय है। इस थ्रेड पर बताए गए सभी मुद्दों को खारिज करना सीधे टाइपस्क्रिप्ट के बताए गए मिशन के साथ संघर्ष करता है, जो कि जावास्क्रिप्ट का "सुपरसेट" होना है (एक सबसेट के बजाय)।

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

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

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

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

समस्या यह है कि यह केवल कोणीय नहीं है जो इन मुद्दों का कारण बनता है। उस स्थिति में कोणीय घाव हो गया क्योंकि यह डीओएम में बहुत से परिदृश्यों को प्रतिबिंबित करता है जहां एक संपत्ति सेट पर ऑटो-जबरदस्ती होती है, लेकिन गेटर हमेशा एक अनुमानित एकवचन प्रकार होता है।

थोड़ा ऊपर की ओर देखें: कोणीय आपके विचार से बहुत खराब है ।

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

class Store {
  private dict: Map<string, any>;

  get name(): string | null {
    return this.dict.get('name') as string | null;
  }

  set name(value: string) {
    this.dict.set('name', value);
  }
}

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

@ फैन-टॉम, इस मुद्दे को फिर से खोलने की आवश्यकता के लिए महान उपयोग-मामला! रखो और आओ।

इस मुद्दे पर अप वोटों की संख्या बहुत अधिक है!

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

typescriptlang.org का मुखपृष्ठ वर्तमान में गलत है जब यह बताता है:

टाइपस्क्रिप्ट जावास्क्रिप्ट का एक टाइप किया गया सुपरसेट है जो सादे जावास्क्रिप्ट को संकलित करता है।

टाइपस्क्रिप्ट जावास्क्रिप्ट के _subset_ का एक टाइप किया हुआ _superset_ है जो सादे जावास्क्रिप्ट में संकलित होता है। :स्माइली:

टाइपस्क्रिप्ट जावास्क्रिप्ट के एक सबसेट का टाइप किया गया सुपरसेट है जो सादे जावास्क्रिप्ट को संकलित करता है।

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

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

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

वर्तमान में, यह संभव नहीं लगता है, और मुझे कुछ इस तरह का सहारा लेना होगा:

class MyClass {

    private _myDate: moment.Moment;

    get myDate(): moment.Moment {
        return this._myDate;
    }

    set myDate(value: moment.Moment) {
        assert.fail('Setter for myDate is not available. Please use: setMyDate() instead');
    }

    setMyDate(value: Date | moment.Moment) {
        this._myDate = moment(value);
    }
}

सबसे अच्छा आप एक कंस्ट्रक्टर को जोड़ सकते हैं और वहां कस्टम सेटर फ़ंक्शन को कॉल कर सकते हैं, यदि केवल उसी समय आप उस मान को सेट कर रहे हैं।

constructor(value: Date | moment.Moment) {
    this.setMyDate(value);
}

सीधे मान निर्दिष्ट करते समय समस्या अभी भी बनी हुई है।

5.5 साल से अधिक समय के बाद इस पर कोई अपडेट?

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

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

@xhliu ... पता करने के लिए बहुत जटिल ...

https://ts-ast-viewer.com/#code/MYewdgzgLgBFCm0DyAjAVjAvDA3gKBkJgDMQQAuGAIhQEMAnKvAXzzwWXQDpSQg

const testObj = {
    foo: "bar"
}

testObj.foo

प्रतीक फू का यह कहना है:

  foo
    flags: 4
    escapedName:"foo"
    declarations: [
      PropertyAssignment (foo)
    ]
    valueDeclaration: PropertyAssignment (foo)

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

इस बिंदु से सट्टा:

यदि यह घोषित करना संभव था (छद्म कोड उदाहरण के लिए) एक accessDelclaration: AccessSpecification (foo) , तो PropertyAccessExpression जो प्रतीक फू और उसकी घोषणाओं से अवगत है, सशर्त रूप से जांच सकता है कि क्या "एक्सेस डिक्लेरेशन" है और इसके बजाय उस से टाइपिंग का प्रयोग करें।

मान लें कि सिंटैक्स उस accessDelclaration संपत्ति को "foo" प्रतीक में जोड़ने के लिए मौजूद है, तो PropertyAccessExpression ts.createIdentifier("foo") से प्राप्त होने वाले प्रतीक से "AccessSpecification" को खींचने में सक्षम होना चाहिए और विभिन्न प्रकार प्राप्त करना चाहिए।

ts.createPropertyAccess(
  ts.createIdentifier("testObj"),
  ts.createIdentifier("foo")
)

अनुमानतः, ऐसा प्रतीत होता है कि इस चुनौती का सबसे कठिन हिस्सा सिंटैक्स (या शायद एक कंपनी दर्शन?) ts.createPropertyAccess() फ़ंक्शन में एक एकल शर्त जोड़ी जाएगी, और उस स्थिति और उसके प्रभावों का प्रतिनिधित्व करने के लिए एक घोषणा वर्ग को ऑब्जेक्ट प्रॉपर्टी के प्रतीक में जोड़ा जाना चाहिए।

बहुत सारे अच्छे उदाहरण लिखे गए हैं कि इसकी सख्त जरूरत क्यों है (विशेषकर डोम और एंगुलर के लिए)।

मैं बस इतना जोड़ूंगा कि पुराने जेएस कोड को टीएस में माइग्रेट करते समय मैं आज इससे प्रभावित हुआ, जहां string से window.location असाइन करने से काम नहीं चला और मुझे as any वर्कअराउंड करना पड़ा मैं

Window.location केवल-पढ़ने के लिए गुण दस्तावेज़ के वर्तमान स्थान के बारे में जानकारी के साथ स्थान ऑब्जेक्ट देता है।

हालांकि Window.location केवल-पढ़ने के लिए स्थान ऑब्जेक्ट है, आप इसे DOMString भी असाइन कर सकते हैं। इसका मतलब है कि आप स्थान के साथ काम कर सकते हैं जैसे कि यह ज्यादातर मामलों में एक स्ट्रिंग थी: स्थान = ' http://www.example.com ' location.href = ' http://www.example.com ' का पर्याय है । .
स्रोत

पुराने JS कोड को TS में माइग्रेट करना जहां string से window.location असाइन करना काम नहीं किया और मुझे as any वर्कअराउंड करना पड़ा

यह एक बढ़िया उदाहरण है।

टीएस को इसकी जरूरत है। यह जावास्क्रिप्ट का एक बहुत ही सामान्य हिस्सा है।

मैं देखता हूं कि वर्तमान मुद्दा बंद कर दिया गया था। लेकिन जैसा कि मैं समझता हूं, इस कार्यक्षमता का एहसास नहीं हुआ था?

@AGluk , इस मुद्दे को फिर से खोलने की जरूरत है।