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

ऐसा लगता है कि यहां यह खुशी है: वर्ग-क्षेत्र-प्रस्ताव , जो कि tc39 समिति के कई वर्षों की पीड़ा के बाद भी stage 3 मिला और यहां तक ​​कि क्रोम में भी इसे लागू किया गया।

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

वर्तमान लापता का विवरण

मैं यहाँ के विवरणों में मूल विवरण , FAQ और परिवर्तनों को नहीं दोहराऊँगा, लेकिन मुख्य बिंदुओं को केवल संक्षेप में बताऊँगा।

क्लास फील्ड्स

खेतों की घोषणा करना और उन्हें एक वर्ग के अंदर उपयोग करना:

 class A { x = 1; method() { console.log(this.x); } } 

कक्षा के बाहर खेतों तक पहुँच:

 const a = new A(); console.log(ax); 

सब कुछ स्पष्ट लग रहा था और कई सालों से हम इस वाक्यविन्यास का उपयोग बैबल और टाइपस्क्रिप्ट का उपयोग कर रहे हैं ।

केवल एक अति सूक्ष्म अंतर है। यह नया सिंटैक्स [[Define]] का उपयोग करता है, न कि [[Set]] शब्दार्थ जिसके साथ हम इस समय रहते थे।

व्यवहार में, इसका मतलब है कि ऊपर का कोड इसके बराबर नहीं है :

 class A { constructor() { this.x = 1; } method() { console.log(this.x); } } 

लेकिन वास्तव में यह इसके बराबर है:

 class A { constructor() { Object.defineProperty(this, "x", { configurable: true, enumerable: true, writable: true, value: 1 }); } method() { console.log(this.x); } } 

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

मान लीजिए कि हमारे पास एक अभिभावक वर्ग है:

 class A { x = 1; method() { console.log(this.x); } } 

इसके आधार पर, हमने एक और बनाया:

 class B extends A { x = 2; } 

और उन्होंने इसका इस्तेमाल किया:

 const b = new B(); b.method(); //   2   

तब, किसी कारण से, क्लास A को एक उचित रूप से पिछड़े संगत तरीके से बदल दिया गया था:

 class A { _x = 1; //  ,   ,        get x() { return this._x; }; set x(val) { return this._x = val; }; method() { console.log(this._x); } } 

और [[Set]] शब्दार्थ के लिए, यह वास्तव में एक पिछड़ा संगत परिवर्तन है, लेकिन [[Define]] । अब b.method() कॉल 2 बजाय 1 कंसोल के लिए आउटपुट होगा। और ऐसा इसलिए होगा क्योंकि Object.defineProperty प्रॉपर्टी डिस्क्रिप्टर को फिर से परिभाषित करता है और तदनुसार, क्लास A से Object.defineProperty / सेटर को नहीं बुलाया जाएगा। वास्तव में, बच्चे की कक्षा में, हमने माता-पिता की x संपत्ति को अस्पष्ट कर दिया , इसी तरह हम इसे लेयिकल में कैसे कर सकते हैं:

 const x = 1; { const x = 2; } 

सच है, इस मामले में, इसके no-shadowed-variable / no-shadow नियमों के साथ लाइनर हमें बचाएगा, लेकिन इस बात की संभावना है कि कोई no-shadowed-class-field को शून्य कर देगा।

वैसे, मैं shadowed लिए अधिक सफल रूसी शब्द के लिए आभारी रहूंगा।

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

यह सच है, यह ध्यान देने योग्य है कि babel7 डिफ़ॉल्ट मान को बदल दिया गया है ।

इस विषय पर अधिक मूल चर्चाएँ यहाँ और यहाँ पढ़ी जा सकती हैं।

निजी क्षेत्र

और अब हम इस एक के सबसे विवादास्पद हिस्से पर आगे बढ़ेंगे। इतना विवादास्पद है कि:

1. इस तथ्य के बावजूद कि यह क्रोम कैनरी में पहले से ही लागू है और सार्वजनिक क्षेत्र पहले से ही डिफ़ॉल्ट रूप से सक्षम हैं, निजी क्षेत्र अभी भी ध्वज के पीछे हैं;
2. इस तथ्य के बावजूद कि निजी क्षेत्रों के लिए प्रारंभिक प्रस्ताव को वर्तमान एक के साथ विलय कर दिया गया था, इन दो सुविधाओं के अलगाव के लिए अनुरोध अभी भी बनाए जा रहे हैं (उदाहरण के लिए, एक , दो , तीन और चार );
3. यहां तक ​​कि कुछ समिति के सदस्य (जैसे एलन विर्फ़्स-ब्रॉक और केविन स्मिथ ) स्टेज 3 के बावजूद बोलते हैं और विकल्प पेश करते हैं ;
4. यह एक याद किया मुद्दों की संख्या के लिए एक रिकॉर्ड सेट - वर्तमान रिपॉजिटरी में 129 + मूल में 96 , बनाम BigInt के लिए , और रिकॉर्ड धारक के पास ज्यादातर नकारात्मक टिप्पणियां हैं ;
5. मुझे किसी तरह इसके खिलाफ सभी दावों को संक्षेप में बताने के प्रयास के साथ एक अलग धागा तैयार करना था;
6. मुझे एक अलग एफएक्यू लिखना था जो इस हिस्से को कवर करता है
   

   हालाँकि, एक कमज़ोर तर्क के कारण, इस तरह की चर्चाएँ सामने आईं ( एक , दो )
   

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

निजी क्षेत्र इस प्रकार घोषित किए गए हैं:

 class A { #priv; } 

और उनकी पहुंच इस प्रकार है:

 class A { #priv = 1; method() { console.log(this.#priv); } } 

मैं इस विषय को भी नहीं उठाऊंगा कि इसके पीछे का मानसिक मॉडल बहुत सहज नहीं है ( this.#priv !== this['#priv'] ), पहले से आरक्षित private / protected शब्दों का उपयोग नहीं करता है (जो जरूरी अतिरिक्त दर्द का कारण होगा। टाइपस्क्रिप्ट डेवलपर्स के लिए), यह स्पष्ट नहीं है कि इसे अन्य एक्सेस संशोधक के लिए कैसे बढ़ाया जाए, और सिंटैक्स स्वयं बहुत सुंदर नहीं है। यद्यपि यह सब मूल कारण था जिसने मुझे गहन अध्ययन और चर्चाओं में भागीदारी के लिए प्रेरित किया।

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

शब्दार्थ WeakMap

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

 const privatesForA = new WeakMap(); class A { constructor() { privatesForA.set(this, {}); privatesForA.get(this).priv = 1; } method() { console.log(privatesForA.get(this).priv); } } 

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

सामान्य तौर पर, सब कुछ बहुत अच्छा होता है, हम hard-private , जो किसी भी तरह से बाहरी कोड से प्राप्त / बाधित / ट्रैक नहीं किया जा सकता है, और साथ ही हम एक ही वर्ग के अन्य उदाहरणों के निजी क्षेत्रों तक पहुंच बना सकते हैं, उदाहरण के लिए:

 isEquals(obj) { return privatesForA.get(this).id === privatesForA.get(obj).id; } 

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

हालांकि कुछ इंजीनियर इसे उचित एनकैप्सुलेशन का एक आवश्यक हिस्सा मानते हैं।

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

संयोग से, मैं अभी भी एक झिल्ली में आया था (हालांकि मुझे नहीं पता था कि यह तब क्या था) जब मैंने अपनी आवश्यकताओं को पूरा करने के लिए vm2 को फिर से लिखा।

brand-checking समस्या

जैसा कि पहले उल्लेख किया गया है, brand-checking duck-typing के विपरीत है। व्यवहार में, इसका अर्थ है कि यह कोड होना:

 const brands = new WeakMap(); class A { constructor() { brands.set(this, {}); } method() { return 1; } brandCheckedMethod() { if (!brands.has(this)) throw 'Brand-check failed'; console.log(this.method()); } } 

brandCheckedMethod को केवल कक्षा A उदाहरण के साथ बुलाया जा सकता है A और भले ही लक्ष्य एक ऐसी वस्तु है जो इस वर्ग के brandCheckedMethod को सुरक्षित रखता है, यह विधि एक अपवाद फेंक देगी:

 const duckTypedObj = { method: A.prototype.method.bind(duckTypedObj), brandCheckedMethod: A.prototype.brandCheckedMethod.bind(duckTypedObj), }; duckTypedObj.method(); //        1 duckTypedObj.brandCheckedMethod(); //      

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

 const a = new A(); const proxy = new Proxy(a, { get(target, p, receiver) { const property = Reflect.get(target, p, receiver); doSomethingUseful('get', retval, target, p, receiver); return (typeof property === 'function') ? property.bind(proxy) : property; } }); 

कॉल proxy.method(); प्रॉक्सी में घोषित उपयोगी कार्य करेंगे और 1 वापस करते हुए, प्रॉक्सी.ब्रांडकैकेडमेथोड proxy.brandCheckedMethod(); कहते हुए proxy.brandCheckedMethod(); प्रॉक्सी से दो बार उपयोगी काम करने के बजाय, यह एक अपवाद फेंक देगा, क्योंकि a !== proxy , जिसका मतलब है कि brand-check पास नहीं हुआ।

हां, हम वास्तविक लक्ष्य के संदर्भ में विधियों / कार्यों को निष्पादित कर सकते हैं, प्रॉक्सी नहीं और कुछ परिदृश्यों के लिए यह पर्याप्त है (उदाहरण के लिए, पैटर्न को लागू करने के लिए), लेकिन यह सभी मामलों के लिए पर्याप्त नहीं है (उदाहरण के लिए, प्रतिक्रियात्मक गुणों को लागू करने के लिए: MobX 5 पहले से ही प्रॉक्सी का उपयोग करता है इसके लिए, Vue.js और ऑरेलिया भविष्य के रिलीज के लिए इस दृष्टिकोण के साथ प्रयोग कर रहे हैं )।

सामान्य तौर पर, जब तक brand-check को स्पष्ट रूप से किए जाने की आवश्यकता होती है, तब तक यह कोई समस्या नहीं है - डेवलपर को जानबूझकर यह निर्णय लेने की आवश्यकता है कि वह कौन सा ट्रेड-ऑफ करता है और क्या उसे इसकी जरूरत है, इसके अलावा, एक स्पष्ट brand-check के मामले में brand-check आप इसे इस तरह से लागू कर सकते हैं। विश्वसनीय प्रॉक्सी पर त्रुटि नहीं डाली जाएगी।

दुर्भाग्य से, वर्तमान ने हमें इस लचीलेपन से वंचित कर दिया है:

 class A { #priv; method() { this.#priv; //    brand-check   } } 

ऐसी method हमेशा एक अपवाद को फेंक देगी यदि इसे कंस्ट्रक्टर A का उपयोग करके निर्मित वस्तु के संदर्भ में नहीं कहा जाता है A और सबसे बुरी बात यह है कि brand-check यहां निहित है और एक और कार्यक्षमता के साथ मिलाया जाता है - एनकैप्सुलेशन।

जबकि किसी भी कोड के लिए लगभग आवश्यक है, brand-check में एक कम संकीर्ण गुंजाइश है। और उन्हें एक वाक्यविन्यास में शामिल करने से तथ्य यह होगा कि उपयोगकर्ता कोड में बहुत सारे अनजाने brand-check दिखाई देते हैं, जब डेवलपर केवल कार्यान्वयन विवरण छिपाने का इरादा रखता है।
और इसको बढ़ावा देने के लिए जो नारा लगाया जाता है वह था # is the new _ केवल स्थिति को बढ़ाता है।

आप यह भी एक विस्तृत चर्चा पढ़ सकते हैं कि कैसे एक मौजूदा प्रोजोल एक प्रॉक्सी को तोड़ता है । ऑरेलिया डेवलपर्स और लेखक Vue.js में से एक ने चर्चा में बात की ।

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

विकल्प

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

1. Symbol.pStreet - एक वैकल्पिक समिति के सदस्यों में से एक prozazil।
   
   1. उपरोक्त सभी समस्याओं को हल करता है (हालांकि इसके अपने भी हो सकते हैं, लेकिन, इस पर सक्रिय कार्य की कमी को देखते हुए, उन्हें ढूंढना कठिन है)
   2. एकीकृत brand-check की कमी, झिल्ली पैटर्न के साथ समस्याओं (हालांकि यह + यह एक पर्याप्त समाधान प्रदान करता है) और सुविधाजनक वाक्यविन्यास की कमी के कारण इसे एक बार फिर समिति की आखिरी बैठक में वापस फेंक दिया गया था।
   3. सुविधाजनक सिंटैक्स वास्तविक एक के ऊपर बनाया जा सकता है, जैसा कि मैंने यहां और यहां दिखाया है
2. कक्षाएं 1.1 - पहले एक ही लेखक से पॉज़ोज़ल
3. वस्तु के रूप में निजी का उपयोग करना

एक निष्कर्ष के बजाय

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

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

यह माना जाता है कि इस मामले में, प्रक्रिया बस विफल रही।

इसे मेरे सिर में डुबोने और कुछ प्रतिनिधियों के साथ बात करने के बाद, मैंने फैसला किया कि मैं एक समान स्थिति की पुनरावृत्ति को रोकने के लिए अपनी पूरी कोशिश करूंगा - लेकिन मैं थोड़ा कर सकता हूं (एक समीक्षा लेख लिख सकता हूं, stage1 के कार्यान्वयन को babel और सभी में याद किया)।

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