12

चूंकि #12 #6532 के साथ बंद हो गया है अब ऐसा लगता है कि यह मुद्दा दायरे से बाहर है।
क्या अब आपके पास विभिन्न एक्सेस संशोधक को लागू करने की कोई योजना है?
क्योंकि readonly जो यहां वर्णित है उसे हल करने के लिए पर्याप्त नहीं है क्योंकि एक संपत्ति वास्तव में एक वर्ग के अंदर लिखने योग्य हो सकती है।

मेरा मानना ​​​​है कि मुझे अपना उदाहरण यहां संबंधित मुद्दे से भी स्थानांतरित करना चाहिए:

declare abstract class Emitter {
    new (): Emitter;
    on: (name:string, handler: (arg:any) => void) => void;
    off: (name:string, handler: (arg:any) => void) => void;
    protected emit: (name:string, arg:any) => void;
}

class Person extends Emitter {
    constructor(name:string) {
        super();
        this.name = name;
    }

    private _name:string;
    get name() {
        return this._name;
    }
    set name(value) {
        if (this._name !== value) {
            this._name = value;
            this.emit('change:name', value);
            //this way is better
            this.updatedAt = new Date();
            //than this way
            this.setUpdatedAt(new Date());
        }
    }

    ////
    private _updatedAt:Date;
    get updatedAt() {
        return this._updatedAt;
    }
    private set updatedAt(value) { //Getter and setter do not agree in visibility
                //some logic and a simple readonly (our absence of a setter) is not enough
        if (this._updatedAt !== value) {
            this._updatedAt = value;
            this.emit('change:updatedAt', value);
        }
    }

    //// method implementation - but what's the point in it?
    private setUpdatedAt(value) {
        if (this._updatedAt !== value) {
            this._updatedAt = value;
            this.emit('change:updatedAt', value);
        }
    }
}

const entity = new Person('Mike');
entity.on('change:updatedAt', console.log.bind(console));
entity.name = 'Thomas';
//but manually setting updatedAt should be forbidden
entity.updatedAt = new Date(); //restricted

यहां, संपत्ति updatedAt में वास्तव में एक सेटर हो सकता है लेकिन इसे Person के बाहर पहुंच योग्य नहीं होना चाहिए । इसके अलावा इस सेटर में जटिल तर्क होते हैं और एक साधारण पठनीय या एक सेटर की अनुपस्थिति पर्याप्त नहीं होती है।

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

इस तरह गेटर्स/सेटर्स C# में कार्यान्वित किए जाते हैं, मुझे लगता है कि संकलन समय पर अलग-अलग दृश्यता की अनुमति देना उपयोगी होगा, हालांकि यह अनुबंध रनटाइम में खो जाएगा।

यहां सिफारिश एक सार्वजनिक रीडोनली गेटर और एक निजी/संरक्षित बैकिंग फ़ील्ड का उपयोग करने की है।

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

वैसे भी इसके लिए मेरा +1 जोड़ना, अगर भविष्य में इसे फिर से माना जाता है ...

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

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

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

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

मैं वास्तव में हैरान था कि आप इस मुद्दे पर TS... +1 में ऐसा नहीं कर सकते।
इसके साथ सीखने की अवस्था में कोई वृद्धि नहीं होनी चाहिए

private get x() { ... }
public set x(value) { ... }

इमो अगर आप अंग्रेजी पढ़ सकते हैं तो यह आत्म-व्याख्यात्मक है कि यहां निजी (संरक्षित)/सार्वजनिक का क्या अर्थ है। इसके अलावा यदि आप एक्सेसर्स को पहले स्थान पर परिभाषित कर रहे हैं - तो आप शायद पहले से ही जानते हैं कि वे किस लिए हैं।

Ps त्रुटि के बारे में: "गेट्टर और सेटर एक्सेसर्स दृश्यता में सहमत नहीं हैं" - ठीक है: ठीक यही मैं उन्हें करना चाहता हूं

यहां दो उपयोग के मामले हैं जहां यह आसान होगा:

Backbone.js, बदसूरत .get() और .set() कॉल से बचने के लिए:

class Whatever {
    public get rotation(): number {
        return this.get('rotation');
    }
    private set rotation(rotation: number) {
        this.set('rotation', rotation);
    }
}

गुण जो उपवर्ग संशोधित कर सकते हैं:

class ExtendMe {
    public get someProperty(): string {
        // some stuff
    }
    protected set someProperty(prop: string) {
        // some stuff
    }
}

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

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

मैं आप लोगों को यह दावा करते हुए पढ़ रहा हूं कि यह बहुत जटिल है। "सी ++ तरीका" याद रखना कि यह अलग क्यों है:

private _myAttribute: string;
get myAttribute(): string {...}
setMyAttribute(value: string) {...}

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

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

"यह बहुत कठिन है" कभी भी अविश्वसनीय रूप से उपयोगी सुविधा को लागू न करने का कारण नहीं होना चाहिए।

मेरा +1 जोड़ना। मुझे यह बहुत अजीब लगता है कि एक ऐसी भाषा में जो इतने सारे मामलों में पूरी तरह से है, आप ऐसा नहीं कर सकते।

यह जानकर आश्चर्य हुआ कि इस मुद्दे को बंद के रूप में चिह्नित किया गया है। यह सुविधा समुदाय द्वारा वांछित है। कृपया फिर से खोलें।
+1

12 इस मुद्दे को संबोधित नहीं करता है, इसलिए इस मुद्दे को उस टिप्पणी के साथ समाप्त नहीं किया जाना चाहिए जो उस मुद्दे को संदर्भित करता है।

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

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

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

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

@idchlife set संपत्ति लक्ष्य डेवलपर्स को मूल्य निर्दिष्ट करते समय एक अंडरस्कोर को सहेजना नहीं है। आप set प्रक्रिया में कुछ तर्क जोड़ना चाह सकते हैं।

कृपया इस मुद्दे को फिर से खोलें। यह स्पष्ट रूप से एक अत्यधिक वांछित विशेषता है।

+1 मुझे इस पर पुनर्विचार करना अच्छा लगेगा।

बहुत अजीब आपका तर्क यह है कि "यह चीजों को भ्रमित कर देगा" जब कई अन्य भाषाएं पहले से ही ऐसा करती हैं।

चूंकि सभी s बहुत कुछ नहीं कर रहे हैं, मैं सिर्फ एक और टिप्पणी के साथ स्पैम करूंगा।

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

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

public string myPropertyWithLimitedAccess { get; private set; }   

उस ओर देखो। खूबसूरती से पठनीय, और जटिल करने के लिए पूरी तरह से कुछ भी नहीं।

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/auto-implemented-properties

समर्थन न करने का कोई कारण नहीं है:

private _myProperty: string;

public get myProperty(): string { return this._myProperty; }
private set myProperty(value: string) { this._myProperty = value; }

अजीब डिजाइन निर्णयों में बोनस अंक, क्योंकि टाइपस्क्रिप्ट मुख्य रूप से .NET डेवलपर्स के लिए ब्राउज़र फ्रंट-एंड के साथ काम करने के लिए अधिक अभ्यस्त होने के लिए बनाया गया था।

+1
टाइपप्रति निश्चित रूप से इस कार्यक्षमता से लाभान्वित होगा!

टाइपस्क्रिप्ट सी # के बाद भी बहुत अच्छा है, लेकिन यह व्यर्थ सीमा मुझे अक्सर परेशान करती है। कृपया इसे फिर से खोलें।

भाषा की जटिलता में वृद्धि होगी

क्या यह वास्तव में readonly [P in keyof T]: T[P] जैसी चीजों की तुलना में यह जटिल है?

टक्कर। यह फीचर हर कोई चाहता है। क्या टाइपस्क्रिप्ट समुदाय को निर्णय नहीं लेना चाहिए?

भाषा की जटिलता में वृद्धि होगी

क्या यह वास्तव में readonly [P in keyof T]: T[P] जैसी चीजों की तुलना में यह जटिल है?

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

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

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

और व्यक्तिगत रूप से, मुझे लगता है कि इस मामले में ट्रेड-ऑफ 1000% है। लेकिन अगर मुझे इसका अनुमान लगाने और इसे काम करने के लिए परेशान नहीं किया जा सकता है, तो मुझे लगता है कि मुझे शिकायत करने का बहुत अधिक अधिकार नहीं है।

क्या यह इस मुद्दे पर फिर से विचार करने का अच्छा समय होगा?

readonly संशोधक बहुत अच्छा है, लेकिन ऐसे कई मामले हैं जहां आप कक्षा के अंदर मूल्य को बदलने में सक्षम होना चाहते हैं और अभी भी सब कुछ केवल पढ़ने के लिए बाहर है।

मैं अक्सर संपत्ति readonly नहीं बनाने का विकल्प चुनता हूं क्योंकि मुझे वह शोर पसंद नहीं है जो एक निजी समर्थन क्षेत्र + गुण जोड़ता है।

यह बहुत अच्छा होगा यदि आपके लिए ऐसा करने के लिए कुछ वाक्यात्मक चीनी हो। कुछ इस तरह:

// Option 1: C# style
public name: string { get; private set; }

// Option 2: Swift style
private(set) name: string

// Option 3: Swift struct-style
public readonly name: string

mutating changeName(name: string) {
  this.name = name
}

// Option 4: New keyword
public frozen name1: string
public readonly name2: string

मुझे विकल्प 2 पसंद है, आईएमओ यह टाइपस्क्रिप्ट भाषा में अच्छी तरह फिट होगा।

विकल्प 3 के साथ, आप केवल mutating . के रूप में चिह्नित फ़ंक्शन में केवल पढ़ने योग्य फ़ील्ड बदल सकते हैं

विकल्प 4 के साथ, frozen को केवल कंस्ट्रक्टर में सेट किया जा सकता है, readonly को इस वर्ग के अंदर सेट किया जा सकता है, न कि इस वर्ग से विरासत में मिली किसी बाहरी कक्षा या वर्ग द्वारा।

संदर्भ के लिए, अधिक लचीले संशोधक पर @yvbeek के विचार https://github.com/microsoft/TypeScript/issues/37487 पर चर्चा के लिए बेहतर अनुकूल हैं।

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

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

@snarfblam इस सूत्र को एक अप्रासंगिक टिप्पणी से रोकना नहीं है, लेकिन मुझे लगता है कि आपने सरकार के संचालन के तरीके के लिए एक मूल सिद्धांत का खुलासा किया है।

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

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

यह सुविधा _Optional chaining_ के समान पथ का अनुसरण कर सकती है। लोग इस सुविधा के लिए वर्षों तक मांग करेंगे और फिर अंत में इसे भाषा में जोड़ दिया जाएगा, क्योंकि यह व्यावहारिक है और अन्य भाषाएं समान सुविधा प्रदान करती हैं।

अन्यथा मुझे उम्मीद है कि कुछ कार्यान्वयन एक्मास्क्रिप्ट का हिस्सा बन जाएंगे और फिर टाइपस्क्रिप्ट के लिए अपना रास्ता बना लेंगे।

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

मैंने इस तरह गेटर्स के साथ सी # के समान कुछ हासिल किया:

export class I18nService {
  private static ref: I18nService;

  public static get instance(): I18nService {
    if (!I18nService.ref) {
      I18nService.ref = new I18nService();
    }

    return I18nService.ref;
  }
}

टाइप एरर जैसे निम्नलिखित समझने में आसान हैं और जटिल नहीं हैं:

Property 'foo' is writable only in protected scope within class 'Blah' and its subclasses.

या

Property 'foo' is readable only in protected scope within class 'Blah' and its subclasses.

आदि, और private के समान।

यह ईमानदारी से जटिल नहीं है।

बीटीडब्लू, मैं भी इस समस्या पर ठोकर खाई, और मैं इस बीच इस तरह के "हैक" का उपयोग कर रहा हूं:

// somewhere.ts
declare global {
    type Writable<T> = { -readonly [P in keyof T]: T[P]; }
}

// example.ts
class Example {

    public readonly prop: number;

    public doSomething(n: number): void {
        (this as Writable<this>).prop = n;
    }
}

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

बीटीडब्लू, मैं भी इस समस्या पर ठोकर खाई, और मैं इस बीच इस तरह के "हैक" का उपयोग कर रहा हूं:

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