तो पहले उदाहरण में, हम इसे निम्न की तरह उत्सर्जित कर सकते हैं:

x && xy && xyz && xyzfoo

लेकिन फिर हमें किसी तरह x, y, z, और foo प्रत्येक का मूल्यांकन एक बार में करना होगा।

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

उदाहरण के लिए:

"     "?.trim()?.indexOf("hello")

"" देता है।

इसलिए आपको सामान्य स्थिति के लिए == $ का उपयोग करके $ null से कुछ स्पष्ट तुलना करने की आवश्यकता है, जब तक कि हम टाइप सिस्टम का लाभ नहीं उठाते (जो हमें करते हुए देखने के लिए काफी अच्छा होगा)।

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

इसके बारे में चर्चा में कुछ चर्चाएं हुई हैं:

• http://esdiscuss.org/topic/the-existential-operator
• http://esdiscuss.org/topic/specifying-the-existential-operator-using-abrupt-completion

:+1:

आदर्श रूप से हमारे पास ES7 (या ES8 या ES9 या ...) पहले इसे लागू करेंगे क्योंकि वास्तव में 0 / "" का उपयोग करने या न करने के बारे में सटीक शब्दार्थ के बारे में शायद कुछ असहमति होगी।

: +1: मैं यह देखना चाहता हूं कि टाइपस्क्रिप्ट इसे पहले ESxx की प्रतीक्षा किए बिना प्राप्त करता है।

तथ्य यह है कि सरल और बेहद उपयोगी नल-सुरक्षा ऑपरेटरों जैसे "?।" और "?:" ES6 स्पेक में नहीं हैं इसका मतलब है कि ES6 स्पेक को एक साथ रखने वाले लोगों को शर्म से अपना सिर लटका देना चाहिए। यह इतनी सरल और स्पष्ट बात है कि इसे शामिल न करना स्पष्ट रूप से पागलपन होगा। एक कारण है कि अधिकांश आधुनिक भाषाएँ इनका समर्थन करती हैं: वे अपरिहार्य हैं।

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

मैं दिमाग से पूरी तरह सहमत हूँ428

@ ब्रायन 428 यहां समस्या यह है कि उस ऑपरेटर को ईएस 7 में लागू किया जा सकता है, इसलिए यदि टाइपस्क्रिप्ट एक विनिर्देश के साथ जाता है जो अंतिम ईएस 7 एक से अलग होता है, तो कोई भी खुश नहीं होगा।

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

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

टाइपस्क्रिप्ट से प्रभावित होने वाली ES चर्चा का एक उदाहरण यहां दिया गया है:

टाइपस्क्रिप्ट... कंस्ट्रक्टर के मापदंडों में से एक पर एक निजी उपसर्ग के माध्यम से घोषित करने और आरंभ करने का विकल्प कई डेवलपर्स के लिए सहायक होगा

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

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

मुझे ध्यान देना चाहिए कि हम मोटे तौर पर इसे सबसे खराब स्थिति मानते हैं। टाइपस्क्रिप्ट 1.0 घोषित करने से पहले हम वास्तव में ES6 में मॉड्यूल को अंतिम रूप देना चाहते थे, लेकिन समिति के शेड्यूल में देरी ने इसे रोक दिया। यह कुछ ऐसा है जिसे टाला जाना चाहिए, दोहराया नहीं जाना चाहिए। हम वास्तव में उन विशेषताओं को हिट करना चाहते हैं जिनके पास इसे ES7+ (जैसे एनोटेशन टाइप करने) में बनाने का ~ 0% मौका है, या इसे आसानी से परिभाषित अर्थशास्त्र के साथ बनाने का ~ 100% मौका है (उदाहरण के लिए जहां वसा तीर दो था साल पहले)। नए ऑपरेटरों के अजीबोगरीब बीच में गिरने की संभावना है।

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

अंततः, ऐसी किसी भी सुविधा का उपयोग—हालांकि अत्यधिक उपयोगी—डेवलपर्स द्वारा आवश्यक नहीं है। TS को इसके उपयोग के संभावित भावी प्रभावों को पहले दिन से ही स्पष्ट रूप से स्पष्ट कर देना चाहिए। संभावित प्रबंधित रिफ्लेक्टर का विचार पसंद नहीं है, इसका उपयोग न करें। शायद इस संदेश को लागू करने के लिए एक ऑप्ट-इन कंपाइलर ध्वज?

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

हो सकता है कि हम इसके लिए एक स्ट्रॉमैन प्रस्ताव को एक साथ रख सकें और फिर --हार्मनी ध्वज (या ऐसा कुछ) के पीछे एक संदर्भ कार्यान्वयन कर सकें। इस तरह हम इस सुविधा के ES7 विकास को आगे बढ़ा सकते हैं।

बार-बार लुक-अप के कारण होने वाले दुष्प्रभावों को रोकने के लिए, कंपाइलर को या तो अस्थायी चर का उत्पादन करना होगा:

($tmp0 = x, $tmp0 === void 0 ? void 0 : 
    ($tmp1=$tmp0.y,  $tmp1 === void 0 ? void 0 : 
        ($tmp2 = $tmp1.z,  $tmp2 === void 0 ? void 0 : $tmp2)))

या Proxy के आधार पर एक यादगार झिल्ली का उपयोग करें।

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

कोडप्लेक्स मुद्दे में काफी वोट थे (61)

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

यह कॉफ़ीस्क्रिप्ट कोड में बहुत मुहावरेदार है (हालाँकि मैं चाहूंगा कि यह उतना लोकप्रिय न हो जितना कि नियतत्ववाद एक धूर्त ? से बेहतर है)। किसी भी कॉफ़ेस्क्रिप्ट फ़ाइल को खोलें, विशेष रूप से वह जो सीधे स्पेस-पेन की तरह डीओएम के साथ काम करती है (जहां दृश्य नष्ट होने के बाद या दृश्य संलग्न होने से पहले कार्य चल सकते हैं) और आपको एक गैज़िलियन ? उपयोग मिलेगा। उदाहरण के लिए इस फ़ाइल में 16 है https://github.com/atom-community/autocomplete-plus/blob/f17659ad4fecbd69855dfaf00c11856572ad26e7/lib/suggestion-list-element.coffee

फिर से मुझे यह पसंद नहीं है कि मुझे इसकी आवश्यकता है, लेकिन यह जावास्क्रिप्ट की स्थिति है, और मुझे एक मिलियन if( && fest ) { then } की बजाय ? #$ चाहिए

लेकिन मुझे अपने कोड को पठनीय रखने के लिए वास्तव में इसकी आवश्यकता है। यह _need_ के लिए भी बहुत आम है जब आप XHR के पूरा होने की प्रतीक्षा कर रहे होते हैं और कोणीय अपना डाइजेस्ट लूप चलाता है।

ठीक है अब मैंने धागा पढ़ लिया है और देखें कि हम प्रतीक्षा क्यों कर रहे हैं। मैं _sigh_ समझता हूँ।

we'd have to somehow make x, y, z, and foo each evaluate at most once.

कॉफ़ीस्क्रिप्ट कुछ अनुकूलन करता है जैसे इंटरमीडिएट एक्सेस परिणाम स्टोर करता है:

typeof foo !== "undefined" && foo !== null ? (ref = foo.bar) != null ? ref.baz() : void 0 : void 0;

(मुझे दृढ़ता से लगता है कि टाइपस्क्रिप्ट के लिए undefined चेक अनावश्यक है: क्योंकि हमारे पास टाइपस्क्रिप्ट द्वारा var init टाइपचेक किया जाना चाहिए)

+1

आज समाचारों में, डार्ट को इसके लिए आधिकारिक समर्थन मिल रहा है: https://github.com/gbracha/nullAwareOperators/blob/master/proposal.md

बहुत महत्वपूर्ण विशेषता।

संभवत: एक ऑफ-द-वॉल विचार है, लेकिन इस सुविधा के लिए कोडजन को बिना किसी साइड इफेक्ट के बहुत आसानी से किया जा सकता है यदि सभी ने फैसला किया कि कुंजी की संपत्ति के उपयोग के साथ सुविधा को संभालना ठीक होगा:

if (aaa?.bbb?.ccc) {}

करने के लिए संकलित कर सकता है

if (__chain(aaa, "bbb", "ccc")) {}

__chain फ़ंक्शन को __extends के समान उत्सर्जित करना होगा। __chain फ़ंक्शन केवल arguments सरणी के माध्यम से पुनरावृति कर सकता है, null लौटाता है जब आगामी सदस्य instanceof Object नहीं होता है या इसमें सदस्य का नाम नहीं होता है। फ़ंक्शन कॉल को एक पैरामीटर के रूप में एक सरणी में पास करके (और कवर के तहत .apply() का उपयोग करके) संभाला जा सकता है, इसलिए ...

if (aaa?.bbb?.ccc?(1, 2, 3)) {}

करने के लिए संकलित कर सकता है

if (__chain(aaa, "bbb", "ccc", [1, 2, 3])) {}

यह लंबी श्रृंखलाओं के लिए भी उत्पन्न जेएस को यथोचित मुहावरेदार बनाए रखेगा।

स्पष्ट रूप से शोधन की आवश्यकता है ... लेकिन शायद यहाँ कुछ है?

यदि aaa?.bbb?.ccc? a.b.c का मान लौटाता है यदि सभी प्रॉप्स मौजूद हैं और यह एक फ़ंक्शन होता है, तो नहीं कर सकता

if (aaa?.bbb?.ccc?(1, 2, 3)) {}

करने के लिए संकलित करें

if (__chain(aaa, "bbb", "ccc")(1, 2, 3)) {}

?

@metaweta : आपका समाधान केवल void 0 के लिए जाँच कर रहा है ... क्या उस तरह की हार सुविधा के उद्देश्य को पूरा नहीं करती है?

इस बारे में क्या:

var result = one?.two?.three;

उत्पन्न करता है:

var $a, $b, $c;
var result = $a = one, $b = $a ? $a.two : void 0, $b ? $b.three : void 0;

मुझे पूरा यकीन है कि यह सभी मामलों को संभालता है। फ़ंक्शन कॉल के लिए शायद instanceof Function चेक की आवश्यकता होगी।

(अप्रत्याशित स्थानीय चरों के उत्सर्जित होने का मामूली नकारात्मक पहलू ... शायद आईआईएफई में लपेटा जा सकता है)

@ kevinb7 : यदि ccc कोई फ़ंक्शन नहीं है तो क्या होगा? आपके द्वारा वर्णित कोड के साथ, __chain को हमेशा एक वैध फ़ंक्शन वापस करना होगा, या एक TypeError उत्सर्जित होगा।

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

@metaweta : नहीं, यह नहीं है: http://jsfiddle.net/25LppbL6/

साथ ही, मुझे लगता है कि टीएस टीम इस तथ्य के कारण ढीली समानता का उपयोग करने के बारे में पागल नहीं है कि कुछ लोगों के लिंटर इसके खिलाफ चेतावनी देते हैं।

@ बैक-आईओ हाँ यह करता है: http://jsfiddle.net/25LppbL6/2/

@ बैक-आईओ शून्य के संबंध में, मुझे यकीन नहीं है कि a?.b का इच्छित अर्थशास्त्र क्या है। यदि यह "यदि संपत्ति बी परिभाषित है तो इसका उपयोग करें", तो मेरा कोड लगभग सही है। जिस तरह से आप अशक्त हो जाते हैं, वह यह है कि यदि इसे अशक्त माना जाता है, क्योंकि गैर-मौजूद गुणों के लुकअप अपरिभाषित होते हैं। यह उस मामले को पकड़ने में विफल रहता है जहां संपत्ति मौजूद है लेकिन अपरिभाषित पर सेट है। पूरी तरह से सही होने के लिए, यह शून्य 0 === अपरिभाषित की तुलना करने के बजाय Object.hasOwnProperty() से जांच करेगा।

यदि शब्दार्थ "यदि गुण b सत्य है तो उसका उपयोग करें" हैं, तो आपका कोड ठीक है और कुछ हद तक JS मुहावरे से मेल खाता है।

उम्म ... जब तक कि मुझे कुछ याद नहीं आ रहा है ... आपके द्वारा बेला में किए गए परिवर्तन मुझे और भी सही साबित करते हैं ... var result अभी भी सभी 3 मामलों में undefined है। और मुझे यकीन नहीं है कि आप किस मामले को आदिम प्रोटोटाइप का विस्तार करके आगे लाने की कोशिश कर रहे हैं ...

मुझे पूरा यकीन है कि सुविधा का व्यवहार त्रुटि उत्पन्न करने के बजाय void 0 के साथ शॉर्ट सर्किट करना होगा। (मुझे ऊपर आपका विचार पसंद है कि लापता सदस्य के मामले में इसे हमेशा शून्य 0 वापस करना चाहिए)।

''?.toString का इच्छित आउटपुट क्या है?

@ kevinb7 : यदि ccc कोई फंक्शन नहीं है तो क्या होगा? आपके द्वारा वर्णित कोड के साथ, __chain को हमेशा एक वैध फ़ंक्शन वापस करना होगा, या एक TypeError उत्सर्जित होगा।

अच्छी बात।

@metaweta : मुझे लगता है कि ज्यादातर लोग toString फ़ंक्शन के संदर्भ की अपेक्षा करेंगे, इसलिए मैं देखता हूं कि आपका बिंदु कहां है, यह उस मामले में कुछ हद तक टूट जाता है जहां आप 0 के प्रोटोटाइप सदस्यों तक पहुंच रहे हैं, झूठा, या ''।

:+1:
कोणीय 2 ने एल्विस ऑपरेटर को उनके टेम्पलेट सिंटैक्स में जोड़ा

@मेटावेटा :

''?.toString'' का इच्छित आउटपुट क्या है?

यदि आपका मतलब ''?.toString() है तो यह होगा:

if ('' != null) {
  ''.toString();
}

नमूना

हो सकता है कि हम इसके लिए एक स्ट्रॉमैन प्रस्ताव तैयार कर सकें

@ kevinb7 यह पहले से मौजूद है: http://wiki.ecmascript.org/doku.php?id=strawman :existential_operator

मैंने इसे विशेष मामले के रूप में PropertyAccessExpression के शीर्ष पर लागू करने के लिए कुछ त्वरित परीक्षण किए लेकिन अच्छी तरह से काम नहीं किया क्योंकि हमें वास्तव में ?. की आवश्यकता है ताकि सही सहयोगी हो (बाएं सहयोगी के बजाय . ) अन्यथा एमिटर अनावश्यक रूप से जटिल हो जाता है।

यहां ब्रेंडनईच की टिप्पणी है जो इसे भी दर्शाती है।

मैंने इसे इसके विशेष मामले के रूप में PropertyAccessExpression के शीर्ष पर लागू करने के लिए कुछ त्वरित परीक्षण किए लेकिन हमें वास्तव में आवश्यकता के अनुसार अच्छी तरह से काम नहीं किया? सही सहयोगी होने के लिए (बाएं सहयोगी की तरह।) अन्यथा एमिटर अनावश्यक रूप से जटिल हो जाता है।

@ बासरत क्या आप उस पर विस्तार से बता सकते हैं? दाएं सहयोगी और बाएं सहयोगी ?. के बीच अंतर का एक उदाहरण मेरे लिए बहुत उपयोगी होगा।

@zlumer

दाएँ साहचर्य और बाएँ साहचर्य के बीच अंतर का एक उदाहरण? मेरे लिए बहुत मददगार होगा।

. को साहचर्य छोड़ दिया जाता है इसलिए अभिव्यक्ति foo?.bar?.baz AST में बन जाती है (यदि हम ?. को समान मानते हैं):

                    // foo.bar.baz = PropertyAccessExpression
                    //   .expr foo.bar =  PropertyAccessExpression
                    //     .expr foo = Identifier
                    //     .name bar = Identifier
                    //   .name baz = Identifier

जावास्क्रिप्ट उत्सर्जन की जरूरत है

foo != null ? (ref_1 = foo.bar) != null ? ref_1.baz() : void 0 : void 0;

यह उत्सर्जन करना आसान है (विशेषकर _recursively_) यदि हमारे पास एएसटी में निम्नलिखित थे:

                    // foo.bar.baz = PropertySafeAccessExpression
                    //   .name foo =  Identifier
                    //   .expr bar.baz = PropertySafeAccessExpression
                    //      .expr bar = Identifier
                    //      .name baz = Identifier

ज़रा सोचिए कि आप पहले AST को JavaScript_ में कैसे बदलेंगे और जटिलताएँ स्पष्ट होंगी। आशा है कि यह मदद करता है: गुलाब:

@zlumer , @basarat ने जो कहा, उसे जोड़ने के लिए, मैं केवल उदाहरण 1 + 2 + 3 डालूंगा।

पार्स करते समय, हमें यह तय करना होगा कि इनमें से कौन सा ऑपरेशन पहले होगा।

यदि + बाएं-सहयोगी है, तो इसे ((1 + 2) + 3) के रूप में व्याख्यायित किया जाएगा।

यदि + सही-सहयोगी है, तो इसकी व्याख्या (1 + (2 + 3)) के रूप में की जाएगी।

आप सवाल कर सकते हैं कि क्या इससे वास्तव में कोई फर्क पड़ेगा। जावास्क्रिप्ट में यह होगा! उदाहरण पर विचार करें "hello" + 2 + 3 ।

• वाम-सहयोगी: (("hello" + 2) + 3) => ("hello2" + 3) => "hello23"
• राइट-एसोसिएटिव: ("hello" + (2 + 3)) => ("hello" + 5) => "hello5"

(रिकॉर्ड के लिए, जावास्क्रिप्ट/टाइपस्क्रिप्ट + ऑपरेटर के लिए लेफ्ट-एसोसिएटिविटी का उपयोग करता है।)

@basarat , मेरी समझ @BrendanEich ने क्या कहा (और अगर मैं गलत हूं तो वह मुझे सही कर सकता है - पिंग के लिए खेद है!) _not_ है कि ?. सही-सहयोगी है, लेकिन कॉफीस्क्रिप्ट विशेष मामलों की संपत्ति पर पहुंच ?. का अधिकार-सहयोगी होने का अधिकार। उदाहरण के लिए, यह पार्स करेगा

o.p?.q.r.s

जैसा

((o . p) ?. (q . (r . s))) # or something close to this

के बजाय

((((o . p) ?. q) . r) . s)

क्योंकि इसे उत्सर्जित करना आसान है।

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

@basarat @DanielRosenwasser स्पष्टीकरण के लिए धन्यवाद। अब तक मैं इसे समझता हूं, लेकिन मैं अभी भी एक बात के बारे में निश्चित नहीं हूं।
वाम-सहयोगी ?. बहुत स्पष्ट और अपेक्षित है:

foo?.bar?.baz

हो जाता है (लगभग):

var ref = ((ref = foo) == null) ? null : ((ref = ref.bar) == null) ? null : ref.baz;

लेकिन मुझे बिल्कुल भी समझ नहीं आ रहा है कि एक राइट-एसोसिएटिव ?. कैसे काम करेगा। क्या आप कृपया एक उदाहरण प्रदान कर सकते हैं?

लेकिन मुझे बिल्कुल समझ में नहीं आता कि एक राइट-एसोसिएटिव कैसे होगा? काम। क्या आप कृपया एक उदाहरण प्रदान कर सकते हैं

@zlumer रनटाइम व्यवहार को सहयोगी छोड़ दिया जाएगा। मैं सिर्फ एएसटी के बारे में बात कर रहा था क्योंकि डैनियल रोसेनवासर ने भी स्पष्ट किया: is not that ?. is right-associative, but that CoffeeScript special cases property accesses on the right of the ?. to be right-associative ।

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

@DanielRosenwasser प्रतिक्रिया के लिए धन्यवाद: गुलाब:

@ बासरत धन्यवाद, अचानक यह सब स्पष्ट हो गया: स्माइली:

@basarat की फ़रवरी टिप्पणी के समान, मैं.... _sigh_...

हालाँकि, यदि आप इसके बारे में सोचते हैं, तो इसका 99% उपयोग मामलों में किसी वस्तु के लिए एक नल पॉइंटर के विरुद्ध जाँच करना होगा। सच कहूं, तो x?.b?.c कौन करता है जबकि x एक number है? जब हम _not_ किसी वस्तु के बारे में बात कर रहे होते हैं ( string के संभावित अपवाद के साथ)। छोटी श्रृंखलाओं के लिए, मुझे लगता है कि हम x && x.b या x === 0 ? null : x.b के साथ रह सकते हैं।

तो, क्या हम कह सकते हैं कि ?. केवल वस्तु प्रकारों पर काम करता है? कोई अन्य प्रकार एक सिंटैक्स त्रुटि फेंकता है। और श्रृंखला के किनारे फ़ंक्शन कॉल को अस्वीकार करें।

फिर पूरी बात a && a.b && a.b.c में बदल जाती है।

@schungx क्या होगा यदि श्रृंखला में कोई सदस्य "कोई" प्रकार है? पूरी तरह से मना करें? या बस इसे जाने दें और सर्वश्रेष्ठ की आशा करें?

अच्छा, मेरा सुझाव? पूरी तरह से मना करें। नरक के रूप में सुरुचिपूर्ण, मुझे पता है... :-)

लेकिन मेरा तर्क:

1. यह एक शॉर्ट-हैंड है, इसलिए यदि कोई any का उपयोग कर रहा है, तो बस लॉन्ग-हैंड का उपयोग करें।
2. यदि कोई टाइपस्क्रिप्ट का उपयोग कर रहा है, तो सबसे अधिक संभावना है कि वह टाइपिंग समर्थन के लिए इसका उपयोग कर रहा है, इसलिए उम्मीद है कि उसके पास बहुत सारे any नहीं होंगे!
3. any को वास्तव में सावधानी से संभाला जाना चाहिए। लचीले प्रकार जैसे any के साथ इस तरह के शॉर्ट-हैंड्स के उपयोग की अनुमति देना वास्तव में बग होने के लिए कह रहा है। मेरी राय में, any जितना संभव हो उतना सीमित होना चाहिए। यह सी के (void *) की तरह है - तथ्य यह है कि आपको एक परमाणु सौंपा गया है इसका मतलब यह नहीं है कि आपको इसे सिर्फ इसलिए ट्रिगर करना होगा क्योंकि आप कर सकते हैं!

यह अद्भुत ऑपरेटर होगा !! विशेष रूप से ES6 / ES7 / TypeScript के लिए

var error = a.b.c.d; //this would fail with error if a, b or c are null or undefined.
var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to handle this
var currentBrackets = a && a['b'] && a['b']['c'] && a['b']['c']['d']; //the current messy way to handle this
var typeScript = a?.b?.c?.d; // The typescript way of handling the above mess with no errors
var typeScriptBrackets = a?['b']?['c']?['d']; //The typescript of handling the above mess with no errors

हालांकि मैं एक और स्पष्ट प्रस्ताव देता हूं - भ्रमित न करने के लिए? ए से? b : c कथन a?.b कथनों के साथ:

var doubleDots = a..b..c..d; //this would be ideal to understand that you assume that if any of a, b, c is null or undefined the result will be null or undefined.
var doubleDotsWithBrackets = a..['b']..['c']..['d'];

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

दो बिंदुओं का अर्थ है कि यदि इसकी अशक्त या अपरिभाषित आगे की प्रक्रिया को रोक देती है और मान लेती है कि अभिव्यक्ति का परिणाम अशक्त या अपरिभाषित है। (जैसा कि d शून्य या अपरिभाषित होगा)।

दो बिंदु इसे और अधिक स्पष्ट, अधिक दृश्यमान और अधिक स्थान-वार बनाते हैं ताकि आप समझ सकें कि क्या हो रहा है।

यह संख्याओं के साथ भी खिलवाड़ नहीं कर रहा है - जैसा कि एक ही मामला नहीं है जैसे

1..toString(); // works returning '1'
var x = {};
x.1 = {y: 'test' }; //fails currently
x[1] = {y: 'test' }; //works currently 
var current = x[1].y; //works
var missing= x[2].y; //throws exception
var assume= x && x[2] && x[2].y; // works but very messy

नंबर दो विकल्पों के बारे में: आपका कॉल जिसे अपनाया जा सकता है, लेकिन मैं मौजूदा नियमों के साथ संगतता के लिए पहले एक की सलाह देता हूं!

1. विफल होना चाहिए जैसा कि अब होता है ( x.1.y == runtime error )

var err = x..1..y; // should fail as well, since 1 is not a good property name, nor a number to call a method, since it's after x object.

1. काम करना चाहिए क्योंकि यह समझता है कि Number.prototype . से किसी संपत्ति को कॉल करने वाला नंबर नहीं है

var err = x..1..y; // should work as well, resulting 'test' in this case
var err = x..2..y; // should work as well, resulting undefined in this case

गतिशील नामों के साथ:

var correct1 = x..[1]..y; //would work returning 'test'
var correct2 = x..[2]..y; //would work returning undefined;

आप लोगों को क्या लगता है?

PS foo?.bar और foo?['bar'] सिंटैक्स भी काम करेगा।

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

उदाहरण के लिए ?. और ?['prop'] उपयोग करना

var a = { x: { y: 1 } };
var b = condition ? a?.x.?y : a?.y?.z;
var c = condition ? a?['x']?['y'] : a?['y']?['z'];

डबल डॉट्स के विपरीत .. और ..['prop']

var a = { x: { y: 1 } };
var b = condition ? a..x..y : a..y..z;
var c = condition ? a..['x']..['y'] : a..['y']..['z'];

आपको कौन सा अधिक स्पष्ट दिखता है?

बहुत ही रोचक। :+1:

IMHO, दो बिंदु अधिक भ्रमित करने वाले होंगे। ऐसी भाषाएं हैं जहां दो बिंदु एक श्रेणी का प्रतिनिधित्व करते हैं (उदाहरण के लिए 1..4 ) और टाइपस्क्रिप्ट भविष्य में इस सुविधा को जोड़ सकता है।

एक प्रश्न चिह्न में अनिश्चितता या सशर्त का अर्थपूर्ण अर्थ भी होता है और दो बिंदु एक ही अर्थ को व्यक्त नहीं करते हैं।

@schungx मेला पर्याप्त है, लेकिन यह इस तरह की अजीब संभावनाओं के लिए मदद करेगा: a?['b'] या यह a?() ।

+1 ?

a?['b'] और a?() कॉफ़ीस्क्रिप्ट में अच्छा व्यवहार करते हैं, और वे मुझे अच्छे लगते हैं।

लेकिन फिर, मैं सिर्फ कॉफ़ीस्क्रिप्ट-अंधा हो सकता हूं।

+1 रूबी ने अभी अस्तित्ववादी ऑपरेटर https://twitter.com/mikepack_/status/657229703443451904 लागू किया है। विशिष्ट सिंटैक्स की परवाह किए बिना टाइपस्क्रिप्ट को भी इसकी आवश्यकता होती है।

यह कोड क्लीनर बना देगा

+1 इसकी आवश्यकता है!

कृपया, लागू करें?. ऑपरेटर, जैसा कि सी # करता है

+1 मैं इसे लंबे समय से याद कर रहा हूं

+1
लिखने के लिए इतना बदसूरत: कुछ परिवर्तनीय && कुछ परिवर्तनीय। कुछ सदस्य
आप कब लिख सकते हैं: कुछ चर?.कुछ सदस्य

+1, यह बहुत अच्छा होगा.... (मेरे लिए सर्वाधिक वांछित विशेषता)

+1, यह एक अच्छा विचार है!
केवल, यदि वस्तु जटिल है, तो व्यंजक ? से भरा होगा। प्रत्येक संपत्ति के बाद (var result=myValue?.a?.b?.c?.d?.e;) जब मुझे पिछले एक का मान प्राप्त करने की आवश्यकता होती है (var result=?myValue.abcde;)।

+1 - यह निश्चित रूप से कॉफीस्क्रिप्ट की सबसे बड़ी विशेषताओं में से एक है और सीएस से टीएस में हमारे अधिकांश कोड को परिवर्तित करने के बाद अब तक मेरी टीम की सबसे वांछित टाइपस्क्रिप्ट सुविधा है।

+1 हालांकि, यह बहुत जटिल है:

var x = { y: { z: null, q: undefined } };
var z: x|y|z = x?.y?.z;

मुझे यह पसंद हे:

var x = { y: { z: null, q: undefined } };
var z: z|void = x?.y?.z;

x?.y?.z का प्रकार हमेशा z फ़ील्ड का प्रकार होता है। बेशक प्रकार शून्य होना चाहिए और वास्तविक मूल्य शून्य हो सकता है। यदि यह गैर-शून्य है, तो यह z फ़ील्ड के प्रकार का होना चाहिए।

+1 यह बड़े पैमाने पर जटिल जेएस परियोजनाओं के विकास को आसान बनाने के टाइपस्क्रिप्ट के दृष्टिकोण के साथ अच्छा होगा।

इस पर कोई अपडेट? क्या यह समुदाय द्वारा इस सुविधा के लिए मतदान करने का मामला है जिस पर विचार किया जाना है? या इस पर विचार किया गया है लेकिन कुछ इंजीनियरिंग चुनौतियां हैं?

अब तक कोई अपडेट नहीं है क्योंकि ईसीएमएस्क्रिप्ट समिति के किसी प्रकार के प्रस्ताव के बिना नए अभिव्यक्ति-स्तरीय सिंटैक्स को पेश करना खतरनाक है।

https://github.com/Microsoft/TypeScript/issues/16#issuecomment -57645069 देखें।

अस्तित्ववादी ऑपरेटरों पर एक और वर्तमान चर्चा यहां दी गई है (बहुत सारे विचार, लेकिन बहुत सारी कार्रवाई की तरह नहीं दिखते):

• एक्ज़िस्टेंशियल ऑपरेटर/नल प्रोपेगेशन ऑपरेटर

इसे ES में लाने में सहायता के लिए मुझे "+1" कहां लिखना चाहिए?

@msklvsk ESDiscuss

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

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

जीवन बेकार है

स्टैंडअलोन हटाना :+1:s. कृपया GitHub प्रतिक्रिया सुविधा का उपयोग करें या अपने निकटतम TC39 प्रतिनिधि को फूल और कैंडी भेजें।

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

@algesten मैं swift के बारे में सहमत हो सकता हूं यदि हम स्वयं भाषा पर विचार करते हैं, दीर्घकालिक coffescript समर्थन के बारे में निश्चित नहीं हैं (मैं उत्पादन परियोजनाओं में कॉफ़ीस्क्रिप्ट का उपयोग करता हूं)। हम जून 2016 के लिए भाषा विश्लेषण प्रवृत्तियों के बारे में सुनिश्चित होने के लिए सहमत हो सकते हैं , जहां हम स्पष्ट रूप से देख सकते हैं कि हाल ही में coffescript में क्या हो रहा है, जबकि TypeScript ने पिछले वर्षों में सबसे तेज वृद्धि देखी है:

टाइपस्क्रिप्ट: गो या स्विफ्ट के बाहर, हाल के वर्षों में हमने जो सबसे तेजी से बढ़ती भाषा देखी है, वह है टाइपस्क्रिप्ट। माइक्रोसॉफ्ट समर्थित जावास्क्रिप्ट सुपरसेट और एंगुलर 2 फाउंडेशन ने लगातार दूसरी तिमाही में महत्वपूर्ण लाभ कमाया है, जो #31 से #26 तक पहुंच गया है। यह किसी भी शीर्ष 30 भाषा में सबसे बड़ा एकल परिवर्तन था, और कुल मिलाकर दूसरी सबसे बड़ी छलांग (स्टैंडर्ड एमएल, 7 स्पॉट)। #26 पर, वास्तव में, टाइपस्क्रिप्ट अब एरलांग के साथ जुड़ा हुआ है, पॉवर्सशेल से एक स्थान पीछे और कॉफीस्क्रिप्ट के पीछे चार, जो शीर्ष 20 से ठीक बाहर है। भाषा के सामने सवाल यह नहीं है कि क्या यह बढ़ सकता है, लेकिन क्या इसमें गति है अगली दो से तीन तिमाहियों में शीर्ष 20 में जगह बनाने के लिए, इस प्रक्रिया में कॉफीस्क्रिप्ट और लुआ की पसंद को आगे बढ़ाते हुए।

2014 तक coffescript रुझान सकारात्मक से अधिक था जैसा कि आप यहां देख सकते हैं , जब गिरावट शुरू हुई थी।

नई टाइपस्क्रिप्ट 2.0 सख्त नल (अपरिभाषित) जांच के साथ, यह जरूरी है, क्योंकि अन्यथा आप फ़ंक्शन चेनिंग का उपयोग नहीं कर सकते हैं!

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

सरल कार्यान्वयन और एक जो जावास्क्रिप्ट में मुहावरेदार होगा, बस शॉर्ट सर्किट के लिए होगा जब या तो अशक्त या अपरिभाषित हो, और अपरिभाषित हो।

@bterlson क्या इसका कोई मतलब है? इस तरह के प्रस्ताव को स्वीकार किए जाने की क्या संभावना है?

टाइपस्क्रिप्ट के महान लाभों में से एक है "भविष्य आज आपको दिया गया है"। यह उन विशेषताओं में से एक है जो मुझे आश्चर्य हुआ कि पहले से ही नहीं हैं।

मुझे उम्मीद है कि इसे जल्द ही जोड़ा जाएगा क्योंकि फंक्शन चेनिंग लोकप्रिय मुहावरा है और सख्त नल जांच करेगा कि यह अब काम नहीं करेगा जब तक कि? ऑपरेटर जोड़ा गया है।

TS 2 अद्भुत अशक्त जाँच ने इसे एक अच्छा से बना दिया है जो होना चाहिए!

इस धागे के माध्यम से पढ़कर मैं आश्चर्यचकित हूं कि रखरखाव से इसे और अधिक ध्यान कैसे नहीं मिलता है।

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

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

• सामान्य तौर पर एक अभिव्यक्ति a?.b संकलन-समय पर मान्य होनी चाहिए यदि और केवल तभी जब a.b मान्य हो।
• इसे केवल एक बार श्रृंखला में प्रत्येक अभिव्यक्ति का मूल्यांकन करना चाहिए।
• यह शॉर्ट-सर्किट होना चाहिए।
• यदि निष्पादन null या undefined मान के साथ मध्य-अभिव्यक्ति तक पहुंचता है तो वह मान वापसी मूल्य होना चाहिए।

आपको क्या लगता है कि जब ES इसे निर्दिष्ट करेगा तो वे कौन से हिस्से हैं जो असहमति पैदा कर सकते हैं?

a?.b के लिए मुझे मौजूदा (और भविष्य?) सिंटैक्स के साथ कोई विरोध नहीं दिख रहा है। यदि पार्सर को टोकन ?. मिल जाता है तो वह इसे 'सुरक्षित नेविगेशन ऑपरेटर' के रूप में मान सकता है (उम्मीदों के साथ @cervengoc द्वारा वर्णित)।

a?(b) और a?[b] की अनुमति देने पर ही सिंटैक्स विरोध उत्पन्न होता है, क्योंकि इनकी व्याख्या एक टर्नरी ?: ऑपरेटर अभिव्यक्ति की शुरुआत के रूप में भी की जा सकती है। लेकिन शुरुआत के लिए मुझे लगता है कि इन्हें अलग रखा जा सकता है और केवल a?.b सिंटैक्स का समर्थन करने से पहले से ही बहुत सारे डेवलपर्स खुश होंगे!

एक आदर्श दुनिया में टाइपस्क्रिप्ट को ES के लिए मार्ग प्रशस्त करना चाहिए न कि इसके विपरीत।

अभिव्यक्ति-स्तर के वाक्य-विन्यास के संदर्भ में, हम पूरी तरह असहमत हैं। एक समिति एक कारण के लिए एक मानक चला रही है - ऐसा नहीं है कि एक खिलाड़ी द्वारा एकतरफा कार्रवाई एकतरफा जावास्क्रिप्ट के भविष्य का फैसला कर सकती है।

यह वाक्यविन्यास वास्तव में "होना चाहिए" है, जैसा कि अन्य ने इसे इंगित किया है।

यदि यह टाइपस्क्रिप्ट के लिए जरूरी है, तो यह जावास्क्रिप्ट के लिए भी जरूरी है! फिर से, अपनी चिंताओं को ईसीएमएस्क्रिप्ट समिति के पास ले जाएं ।

आपको क्या लगता है कि जब ES इसे निर्दिष्ट करेगा तो वे कौन से हिस्से हैं जो असहमति पैदा कर सकते हैं?

कम से कम, मुझे लगता है कि इस बारे में असहमति होगी कि सिंटैक्स शॉर्ट-सर्किट null या undefined उन मानों का सामना करते समय, या हमेशा शॉर्ट-सर्किट undefined । इस बात को लेकर भी कुछ विवाद होने जा रहा है कि किसी प्रकार के ब्रैकेटेड सिंटैक्स का समर्थन किया जाता है या नहीं। यह भी सवाल है कि a?.b.c का व्यवहार क्या है। ?. बनाम .? बनाम a.b? का भी सवाल है। सवाल यह है कि इसका delete ऑपरेटर पर क्या प्रभाव पड़ता है।

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

मैं क्षमा चाहता हूं, मैंने उल्लिखित धागे को नहीं पढ़ा, और अधिक देखने के लिए मैं निश्चित रूप से इसे देख लूंगा।

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

साथ ही, जिन अस्पष्टताओं का आपने उल्लेख किया है वे 99% _theoretical_ चीजों में हैं और डेवलपर की ओर से अप्रासंगिक हैं। कौन इसकी परवाह करेगा कि वह क्या लौटाता है, null या undefined ? बस एक को चुनें, और हम इसे उसी तरह इस्तेमाल करेंगे।

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

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

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

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

कुल मिलाकर, आप और वह समिति हम में से अधिकांश की तुलना में एक अलग पक्ष में हैं, और उस तरफ की चीजें आमतौर पर उससे कहीं अधिक जटिल होती हैं जितनी वे वास्तव में होती हैं।

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

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

तो चीजों के "अलग पक्ष" पर होने से मेरी राय में स्पष्ट रूप से काम किया है। जो "होना चाहिए" सुविधाओं की समीचीनता को हरा देता है।

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

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

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

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

मैं लोगों को एक त्वरित जानकारी देना चाहता था कि आज की TC39 बैठक में यह सुविधा चरण 0 से चरण 1 में स्थानांतरित हो गई है।

प्रासंगिक प्रतिबद्धता: https://github.com/tc39/proposals/commit/cb447642290a55398d483f5b55fb7f973273c75d
बैठक का एजेंडा: https://github.com/tc39/agendas/blob/master/2017/01.md

वाह! वह तो विशाल है!

https://github.com/claudepache/es-Optional-chaining . के लिंक के लायक भी

कुछ "आश्चर्य" मैं यहां देख रहा हूं (यह नहीं कह रहा कि मैं असहमत हूं, बस चीजें जो हम शायद अलग तरीके से करते अगर हमने इसे पहले किया होता):

• null एक a?.b अभिव्यक्ति से निर्मित नहीं है: जब a null है तो यह इसके बजाय undefined उत्पन्न करता है
• ~ जंजीर बिंदुओं में प्रसार: a?.b.c.d फेंक नहीं जाएगा अगर b और c गुण undefined हैं ~ रयान पढ़ नहीं सकता
• ~ माता-पिता की उपस्थिति में प्रचार: (a?.b).c भी नहीं फेंकेगा यदि b अपरिभाषित है ~ रयान पढ़ नहीं सकता
• ~प्रचार विधि कॉल पर भी होता है: a?.b.c().d undefined लौटाएगा यदि c आमंत्रण null वापस आता है ~ रयान पढ़ नहीं सकता
• delete ऑपरेटर समर्थित है
• ब्रैकेटिंग सिंटैक्स a?.[x] समर्थित है
• फ़ंक्शन कॉल सिंटैक्स func?.(...args) समर्थित है, यहां तक ​​कि गैर-विधि कॉल (!)

मुझे अब और चरण 2 के बीच उन क्षेत्रों में परिवर्तन देखने की उम्मीद है।

मुझे लगता है कि कॉफ़ीस्क्रिप्ट ने इसे सही पाया।

a?.bc फेंकता है यदि b अपरिभाषित है।

a?() और a?[0] दोनों अच्छे हैं।

• जंजीर बिंदुओं में प्रसार: a?.bcd नहीं फेंकेगा यदि b और c गुण अपरिभाषित हैं
• माता-पिता की उपस्थिति में प्रसार: यहां तक ​​कि (a?.b).c नहीं फेंकेगा यदि b अपरिभाषित है
• विधि कॉल पर भी प्रचार होता है: a?.bc().d अपरिभाषित वापस आ जाएगा यदि c आमंत्रण शून्य हो जाता है

वे बिंदु मुझे सटीक नहीं लगते। प्रस्ताव से:

a?.b.c().d      // undefined if a is null/undefined, a.b.c().d otherwise.
                // NB: If a is not null/undefined, and a.b is nevertheless undefined,
                //     short-circuiting does *not* apply

वाह, मैंने इसे पूरी तरह से गलत तरीके से पढ़ा। आप सही हे। अद्यतन करने

@algesten मूल प्रस्ताव से:

a?.()

b?.[0]

मिठाई। ऑपरेटर तब ?. के रूप में हो सकता है।

यहाँ कुछ अतिरिक्त बातचीत हो रही है: https://github.com/estree/estree/issues/146

एक उद्धरण जो अच्छी तरह से लागू हो सकता है: «साधारण चीजों को आसान बनाएं, और कठिन चीजों को संभव बनाएं»। इस प्रकार शायद, सबसे आम मामलों का अच्छी तरह से समर्थन करें, जबकि जटिल/दुर्लभ मामलों को छोड़ दें (कम से कम शुरुआत में), जबकि उन्हें अभी भी लंबे (मौजूदा) वाक्यविन्यास के साथ "मैन्युअल रूप से" करने की अनुमति है।

केवल मेरे दो सेंट्स

let a = b?.c?.d?.e;

प्रति:

let a;
try{
   a = b.c.d.e;
}catch(e){
   a = undefined;
}

@cedvdb पूरी तरह से अलग शब्दार्थ - गेटर्स में फेंके गए अपवादों को सहवास का कारण नहीं बनना चाहिए

@RyanCavanaugh हाँ .. मैंने इसके माध्यम से नहीं सोचा था।

क्या यह अभी कार्यान्वयन के लिए रडार पर है, या TS टीम ES के प्रस्ताव के आगे बढ़ने की प्रतीक्षा करेगी?

यह हमारी छोटी सूची में है; हमारे पास अभी भी कुछ प्रश्न/चिंताएं हैं लेकिन आपको आने वाले महीने में इस पर आंदोलन देखना चाहिए।

सुनिश्चित नहीं है कि @mhegazy की टिप्पणी कहाँ से आई - TC39 प्रस्ताव पर खुले प्रश्नों की संख्या हमारे लिए यहाँ सार्थक कार्य करने के लिए बहुत बड़ी है। null और undefined इंटरैक्ट कैसे करते हैं और कौन सा सिंटैक्स वास्तव में समर्थित है, इसके बारे में विशेष रूप से प्रश्नों को पहले संबोधित करने की आवश्यकता है। चरण 2 एक पूर्ण न्यूनतम न्यूनतम है और हम रनटाइम व्यवहार पर प्रभाव को देखते हुए चरण 3 को प्राथमिकता देंगे।

क्या यह बस कोड काम करता है?

a == undefined ? expression : undefined

expression का अर्थ है कुल्हाड़ी, a[x], a(x), delete यहां भी उत्पन्न हो सकता है

तब a?.b?.[c]?.(d) उत्पन्न होगा

a == undefined ? (a.b == undefined ? (a.b[c] == undefined ? a.b[c](d) : undefined) : undefined) : undefined

लगता है सभी रयान कैवानॉघ के शासन से गुजरेंगे

अगर == ऑपरेटर से नफरत है, तो यह a === undefined || a === null . भी हो सकता है

@ zh99998 आपको == से नफरत है क्योंकि '' और 0 भी बराबर हैं। यह लगभग तर्क दिया जाता है कि रनटाइम व्यवहार (typeof value === 'object' || typeof value === 'function' || typeof value === 'symbol') && value !== null पर किसी प्रकार की जांच होनी चाहिए, जो अब जटिल हो रही है।

जैसा कि @RyanCavanaugh ने कहा, इसके आगे बढ़ने की संभावना नहीं है जब तक कि इसके लिए TC39 प्रस्ताव कम से कम चरण 2 या 3 तक नहीं पहुंच जाता।

मुझे == केवल null और undefined के बराबर दिखाई देता है
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness

और परीक्षण क्रोम कंसोल में पारित:

'' == undefined
false
0 == undefined
false

@kitsonk अपरिभाषित केवल अशक्त और इसके विपरीत के लिए मजबूर करता है। कोई अन्य मूल्य अपरिभाषित या शून्य के लिए बाध्य नहीं है।

ऐसा लगता है कि आप झूठे मूल्यों से भ्रमित हैं। 0 और "" वास्तव में झूठे हैं, लेकिन कभी भी अशक्त या अपरिभाषित के लिए बाध्य नहीं होंगे।

== का मतलब जबरदस्ती है। null == 0 झूठा है क्योंकि अपरिभाषित को छोड़कर कुछ भी शून्य पर मजबूर नहीं हो सकता है। वही undefined == 0 के लिए जाता है।

एक और उदाहरण हो सकता है

    if(!NaN) console.log("NaN is falsy") // NaN is falsy
    if(false == NaN) console.log("NaN coerces to false")
   else console.log("NaN doesn't coerce to false");// NaN doesn't coerce

आपको चित्र मिल जाएगा।

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

सौभाग्य से, जावास्क्रिप्ट में आईआईएफई है, इसलिए आप किसी एक्सेसर के परिणाम को फ़ंक्शन पैरामीटर में संग्रहीत कर सकते हैं, जितना चाहें उतना इसका संदर्भ लें और कभी भी इसे एक से अधिक बार मूल्यांकन न करें। नीचे दिए गए मेरे उदाहरण में, मैं एक coalesce लैम्ब्डा बनाता हूं जिसे ?. ऑपरेटरों वाले एक्सप्रेशन के स्थान पर कई बार कॉल किया जा सकता है।

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

const coalesce = (x: any, y: string) => x == null ? null : x[y];

const x = {
    y: {
        z: "Hello, World!!!"
    },
    f: () => "Foo!",
    a: ["Array!"]
};

// x?.y?.z
const value1 = coalesce(coalesce(x, 'y'), 'z');

// x?.f()
const value2 = coalesce(x, 'f')()

// x?.a[0]
const value3 = coalesce(x, 'a')[0]

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

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

यह ?? ऑपरेटर की आवश्यकता को भी सामने लाता है। C# में, यह किसी भी null अभिव्यक्ति को जो कुछ भी दाईं ओर है उसे बदल देता है।

string x = null ?? "Hello";
````

In JavaScript, it is more idiomatic to use `||` to replace "falsey" values with the value on the right. 

```javascript
var x = null || "Hello";

दुर्भाग्य से, सच्चाई बहुत सारे किनारे के मामलों ( 0 , false , आदि) को पकड़ लेती है। एक नल कोलेस ( ?. ), ऑपरेटर के साथ काम करना, आप null -ness के लिए कुछ विशिष्ट चाहते हैं।

const x = { y: "" };
const result1 = x?.y || "default";  // I'd expect "default"
const result2 = x?.y ?? "default";  // I'd expect "" 

@jehugaleahsa , आपके उदाहरण में कोलेस के साथ फ़ंक्शन कॉल और सदस्य पहुंच को होने से रोकने के लिए एक तरीका होना चाहिए यदि चेक शून्य से पहले वापस आ गया हो। x?.f() उदाहरण में, यदि x शून्य है तो f को कॉल नहीं किया जाना चाहिए।

@bschlenk मुझे नहीं लगता कि मैं सहमत हूं। मुझे लगता है कि इसे null is not a function जैसे संदेश के साथ विफल होना चाहिए, लेकिन यह मेरे ऊपर नहीं है, मुझे लगता है।

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

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

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

यह शब्दार्थ है जिसमें अभी भी कुछ अज्ञात हैं, जिन्हें यहां और यहां सूचीबद्ध किया गया है।

निश्चिंत रहें हम इसे सही तरीके से लागू करेंगे और || और ? ... : ... क्या करते हैं, यह जानने के लिए यहां और 100 टिप्पणियों की आवश्यकता नहीं है। जैसा कि @noppa ने नोट किया कि हम ES युक्ति को अंतिम रूप देने की प्रतीक्षा कर रहे हैं।

https://github.com/babel/babel/pull/5813 (बेबीलोन पीआर के साथ) को अभी बाबेल के preset-stage-1 में मिला दिया गया था। कल्पना अभी भी चरण 1 पर है, लेकिन इससे इसे आगे बढ़ने में मदद मिलेगी।

हो सकता है कि मैं गलत हूं, लेकिन मुझे इस धागे में tc39 प्रस्ताव का कोई स्पष्ट लिंक नहीं दिख रहा है, इसलिए यहां यह भविष्य के पाठकों के लिए है: https://github.com/tc39/proposal-Optional-chaining

FYI करें वैकल्पिक श्रृखंला अगले सप्ताह TC39 पर होगी https://github.com/tc39/agendas/blob/master/2017/07.md

@jehugaleahsa मुझे लगता है कि आप सही हैं और मैं अगले सप्ताह TC39 पर ?? पेश करूँगा। आप यहां प्रस्ताव का पालन कर सकते हैं: https://github.com/gisenberg/proposal-nullary-coalescing

मैं देख रहा हूँ कि वैकल्पिक श्रृखंला को TC39 में शामिल किया गया था... फैसला क्या था?
उम्मीद है कि इसे टाइपस्क्रिप्ट में आगे बढ़ाने के लिए पर्याप्त था

@markwhitfeld नोट्स सारांश से:
वैकल्पिक चेनिंग ऑपरेटर्स: स्टेज 1 पर बने हुए हैं, बाद में विभिन्न विकल्पों और फीडबैक के जवाबों के लिए स्पष्ट परिभाषाओं के साथ वापस आएंगे।

यहां पूर्ण नोट्स: https://github.com/rwaldron/tc39-notes/blob/master/es8/2017-07/jul-27.md#13iia -Optional-chaining-operator

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

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

मुझे बहुत उम्मीद है कि वे विकल्प 2/4 के साथ जाएंगे (जो वैसे भी प्रस्ताव की वर्तमान स्थिति है)।

15 जुलाई 2014 - 4 सितंबर 2017, अभी कुछ नहीं

@frankfvb आपने स्पष्ट रूप से इस मुद्दे को नहीं पढ़ा है।

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

ईसीएमएस्क्रिप्ट मानक समिति की पिछली बैठक के अनुसार, प्रस्ताव चरण 1 पर बना हुआ है क्योंकि इसमें कुछ बहुत ही मौलिक प्रश्न हैं कि इसे कैसे लागू किया जाएगा। जबकि एक कठिन और तेज़ नियम नहीं है, टाइपस्क्रिप्ट केवल चरण 3 प्रस्तावों को लागू करेगा। यह कभी-कभी चरण 2 के प्रस्तावों को लागू करता है यदि उन्हें लगता है कि यह महत्वपूर्ण महत्व का है और टाइपस्क्रिप्ट में संभावित रूप से उपयोग मानक के विकास को प्रेरित करता है।

मुझे यकीन नहीं है कि इसके बारे में और अधिक स्पष्ट लोग कैसे हो सकते हैं।

जैसा कि मैंने पहले कहा था कि यह हमारी छोटी सूची में है। हम ऑपरेटर के शब्दार्थ पर किसी प्रकार की आम सहमति तक पहुंचने के लिए TC39 की प्रतीक्षा कर रहे हैं। हम इसे बाहर रखने और फिर उपयोगकर्ताओं को तोड़ने से नफरत करेंगे।

यह TC39 चर्चा को फिर से शुरू करने का सूत्र नहीं है

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

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

टाइपस्क्रिप्ट में एक बहुत ही सरल एल्विस ऑपरेटर को लागू करना

इसके अलावा यदि आपके पास लॉश/अंडरस्कोर है, तो आप पहले से ही _.get(Book, 'author.name.firstName') का उपयोग कर सकते हैं जो वह करेगा जो यह चाहता है

संपादित करें: _.get() विधि के साथ प्रकार के मुद्दों के कारण स्पष्ट रूप से यह बुरी सलाह है। नीचे कमेंट देखें

@tolgaek , _.get में खराब टाइपिंग है, यहां तक ​​​​कि इस बेहतर टाइपिंग के साथ (लेखकों की वजह से अभी तक विलय नहीं हुआ है ) टाइपस्क्रिप्ट निश्चित रूप से परिणाम के प्रकार को तभी निकाल सकता है जब वस्तु की गहराई 1 हो, अन्य सभी मामलों में यह any है

दूसरी ओर एल्विस ऑपरेटर टाइपस्क्रिप्ट किसी भी गहराई के साथ वस्तुओं में परिणाम के प्रकार का अनुमान लगाने में सक्षम हो सकता है, यही कारण है कि मैं एल्विस ऑपरेटर की प्रतीक्षा कर रहा हूं

ओह ठीक है, मुझे नहीं पता था कि टाइपिंग की समस्या थी। धन्यवाद @BjornMelgaard

@mhegazy इस सुविधा को पहले लागू नहीं किया जा सकता है और प्रयोगात्मक सुविधा के रूप में चिह्नित नहीं किया जा सकता है? मुझे लगता है कि प्रायोगिक फीचर में बदलाव होने पर लोगों को समस्या नहीं होनी चाहिए।

एल्विस इतने लंबे इंतजार से खुश नहीं हैं।

यह Babel7 में उतरा है। टाइपस्क्रिप्ट, हम धीमी गति से चल रहे हैं.. कोई कृपया इसे करें।
:)

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

@alangpierce यह समझ में आता है। धन्यवाद

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

कल्पना तैयार होने तक इस टिकट को लॉक (बंद नहीं) करना चाहिए।

युक्ति कब तैयार होने जा रही है?

@oliverjanik वर्तमान मसौदा विनिर्देश यहां पाया जा सकता है। अगली TC39 मीटिंग (9/26-9/28) में चरण 2 के प्रस्ताव को आगे बढ़ाने के लिए एक एजेंडा आइटम है। मैं उस समय ये स्लाइड्स प्रस्तुत कर रहा हूँ। जो लोग जल्दी समीक्षा करना चाहते हैं और प्रतिक्रिया देना चाहते हैं, कृपया प्रस्ताव रेपो पर समस्या दर्ज करें।

हमारे लिए इस मुद्दे को आगे बढ़ाने के लिए @gisenberg का बहुत-बहुत धन्यवाद! मैं ऑपरेटर के आस-पास के विकल्पों को साफ़ करने में मदद करने के लिए एक सारांश स्लाइड डेक को एक साथ रखने के बारे में सोच रहा था जिसे टीसी39 मीटिंग में भ्रम से बचने के लिए इस्तेमाल किया जा सकता था, लेकिन आपने इसे पहले ही कर लिया है। अद्भुत कार्य!
हो सकता है कि केवल एक अन्य चीज जो TC39 वार्तालाप (और स्लाइड डेक) के लिए फायदेमंद हो सकती है, वह है अन्य भाषाओं में ऑपरेटर के शब्दार्थ और वाक्य-विन्यास को देखना। हालांकि अन्य भाषाओं को जरूरी नहीं होना चाहिए कि इसे जावास्क्रिप्ट में कैसे काम करना चाहिए, यह भ्रम से बचने के लिए ऑपरेटर को अन्य भाषाओं के समान रखने में मददगार होगा।
अगले सप्ताह के लिए शुभकामनाएँ !!!

एक बार फिर से विषय से थोड़ा हटकर जाने के लिए क्षमा करें, लेकिन मुझे लगा कि यहां कुछ लोगों को यह दिलचस्प लग सकता है कि फ्लो में अब सुरक्षित गेटर फ़ंक्शंस जैसे _.get के लिए कुछ हद तक काम करने वाली परिभाषाओं को जोड़ना संभव है।

उदाहरण: Flowtype.org/try

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

AFAIK एकमात्र चीज जो टीएस से गायब है, ऐसा करने के लिए वह $NonMaybeType जैसा कुछ है।
ऐसा नहीं है कि यह इस ऑपरेटर की आवश्यकता को दूर करेगा, निश्चित रूप से, मैंने सोचा था कि यह अच्छा था।

ब्रैकेट बनाम डॉट बनाम कॉल एक्सेस और सिमेंटिक व्यवहार के बारे में वाक्यात्मक स्थिरता के बारे में चिंताओं के कारण यह नवीनतम TC39 बैठक में स्टेज 2 तक नहीं पहुंच पाया ( undefined / null के दाईं ओर अभिव्यक्ति के साइड इफेक्ट के आसपास भविष्यवाणी x.?b() जब x.b एक number है)

(वोट इस टिप्पणी पर सड़े हुए फल फेंकने के लिए)

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

हो सकता है कि दायरे को कम करने की जरूरत है, इसलिए यह आसान है लेकिन फिर भी उपयोगी है?

यह वह चुनौती है जिसका TC39 सामना कर रहा है, जबकि मुझे यह स्वीकार करना होगा कि मुझे खुशी है कि लोग इससे गुजर रहे हैं। उनके लिए काफी जटिल स्तर के सिंटैक्स को पेश करना वास्तव में कठिन है और वास्तव में, इस मामले में भाषा की कमजोर टाइपिंग वास्तव में एक महत्वपूर्ण मात्रा में किनारे के मामलों का कारण बन रही है, या आपको कोड मिलता है जो है किसी के लिए अच्छा नहीं है। मुझे नहीं लगता कि अगर आप इस तरह के एक ऑपरेटर को पेश करते हैं तो आप वास्तव में इसके दायरे को कम कर सकते हैं। कार्यान्वयनकर्ताओं के लिए 90% मामलों को कवर करना आसान होगा, लेकिन मुझे नहीं लगता कि ¯\_(ツ)_/¯ शेष 10% के लिए वैध कोड है।

दोस्तों, 3+ साल बाद, मैं कहूंगा कि यह समय है कि आप समिति को "भाड़ में जाओ" और इसे अपने तरीके से करें, जो भी टाइपस्क्रिप्ट के लिए मुहावरेदार है। यह फीचर वैसे भी स्टैटिक टाइपिंग के बिना ठीक से काम नहीं कर सकता है।

एक सिंटैक्स के साथ टाइपस्क्रिप्ट कार्यान्वयन करें जो स्पष्ट रूप से TC39 प्रस्ताव के साथ असंगत है। एक बार जब ES को एक सुरक्षित-एनएवी ऑपरेटर मिल जाता है, तो टाइपस्क्रिप्ट के पास दो विकल्प होंगे: एक चमकदार शब्दार्थ के साथ जो ES के साथ संगत है, और दूसरा जो टाइप सिस्टम से जुड़ा है। इसका मतलब है कि आप किसी भी "प्रकार" के साथ टीएस सुरक्षित-एनएवी ऑपरेटर का उपयोग नहीं कर सकते हैं, और यह ठीक है।

@notsnotso टाइपस्क्रिप्ट जेएस को तोड़ने वाला नहीं है, कॉफीस्क्रिप्ट यही है।

शायद अच्छा समाधान है:

• बहुत सरल लागू करें? अधीर देवों के लिए ऑपरेटर, प्रायोगिक सुविधा (जैसे डेकोरेटर) के रूप में, चेतावनी के साथ - यह भविष्य में आपके कोड को तोड़ देगा
• एक और 3 साल प्रतीक्षा करें जब स्टैंडआर्ट लिखा जाएगा, गैर-प्रयोगात्मक सुविधा के रूप में लागू करें। ट्यूटोरियल लिखें, क्या तोड़ा जा सकता है। यहां तक ​​​​कि, स्थिर टाइपिंग के साथ, चेतावनियां लिखना संभव है जब लोग नए ऑपरेटर कार्यान्वयन के साथ कोड संकलित करेंगे।
  "इसे अपने तरीके से करें, जो कुछ भी टाइपस्क्रिप्ट के लिए मुहावरेदार है" कोई मामला नहीं है, क्योंकि 3 साल में लोगों को समस्या का सामना करना पड़ेगा, कि ts एल्विस उसी तरह काम नहीं करता है जैसे जेएस में होता है।

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

मैं इस समस्या को हल करने वाली एक अधिक सामान्य-उद्देश्य उपयोगिता के बजाय बहुत कुछ करूंगा
और अधिक। एक विचार मेरे पास एक इनलाइन try/catch . जैसा कुछ था
अभिव्यक्ति ( let x = try a.b.c else 0 ) एक ऑपरेटर के साथ संयोजन में कि
"झूठी" के बजाय "नली" (उदाहरण के लिए, x ?? 1) के लिए चेक किया गया (उदा., x || 1)।
तो, आप उन्हें इस तरह संयोजित करेंगे: try a.b.c ?? 0 else 0 । यह चिंताजनक है, हाँ,
लेकिन यह मूल रूप से कहता है: एबीसी का मूल्यांकन करने का प्रयास करें और यदि परिणाम null है या
undefined , वापसी 0. यदि a या b undefined है और एक अपवाद फेंका जाता है,
इसे पकड़ें और 0 लौटाएं।

एक विकल्प यह होगा कि else क्लॉज को वैकल्पिक बनाया जाए, डिफ़ॉल्ट रूप से
undefined । तब आप व्यंजक को इस प्रकार लिख सकते हैं: let x= (try a.b.c) ?? 0 । यह काफी कॉम्पैक्ट है, अस्पष्टता से बचा जाता है और अधिक प्रदान करता है
सामान्य-उद्देश्य समाधान जो अन्य समस्याओं के लिए हल कर सकता है।

मैं यह नहीं कह रहा हूं कि इसके बजाय हमें इसके लिए जोर लगाना चाहिए; मैं बस इतना कह रहा हूं
?. के विकल्प हैं और जब तक हम
वह खोजें जो जावास्क्रिप्ट भाषा के साथ अच्छी तरह से फिट बैठता हो।

गुरु, 5 अक्टूबर, 2017 को सुबह 7:51 बजे, दिमित्री राडकोवस्की नोटिफिकेशन @github.com
लिखा था:

@notsnotso टाइपस्क्रिप्ट जेएस को तोड़ने वाला नहीं है, यही है
कॉफ़ीस्क्रिप्ट के लिए है।

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

@zlumer अच्छा मजाक। उस ने कहा, एक टीएस विशिष्ट सुविधा जावास्क्रिप्ट को नहीं तोड़ेगी।

@jehugaleahsa मुझे आपका प्रस्ताव पसंद है, और यह अन्य भाषाओं में पाया जाता है। मुझे लगता है कि यह टीएस के लिए ठीक काम करेगा।

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

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

प्रारंभिक चरण में टाइपस्क्रिप्ट के लिए async/प्रतीक्षा भी पेश की गई थी।

उस ने कहा, एक टीएस विशिष्ट सुविधा जावास्क्रिप्ट को नहीं तोड़ेगी।

"TS विशिष्ट सुविधा" जैसा कुछ नहीं होगा, कृपया अधिक जानकारी के लिए टाइपस्क्रिप्ट डिज़ाइन लक्ष्य देखें।

_{टाइपस्क्रिप्ट ES के उज्ज्वल रास्ते पर जाने से पहले आता है, कुछ मौजूदा हो सकते हैं,उन्हें सिर्फ अनुकूलता के लिए रखा गया है।}

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

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

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

प्रारंभिक चरण में टाइपस्क्रिप्ट के लिए async/प्रतीक्षा भी पेश की गई थी।

एक बार ईसीएमएस्क्रिप्ट प्रस्ताव स्टेज 3 पर पहुंच गया।

कोई भी गलत व्यवहार नहीं कर रहा है लेकिन अगर यह बातचीत कहीं भी नहीं जा सकती है, लेकिन मंडलियों में (क्या होगा यदि कोई झंडा था? हां हम झंडे के बारे में जानते हैं) या ऑफ-विषय (क्या होगा यदि टीएस जेएस बनना बंद कर देता है? नहीं पांच साल बाद हम नहीं बदल रहे हैं उस पर हमारा दिमाग), हमें इसे रखने की आवश्यकता नहीं है। हमने लगभग 3 वर्षों से कहा है कि हम इसे ठीक उसी समय लागू करेंगे जब ES समिति इसके शब्दार्थ को बंद कर देगी।

एक बार फिर, प्रस्ताव रेपो https://github.com/tc39/proposal-Optional-chaining है और आप वहां इसकी प्रगति का अनुसरण कर सकते हैं। हम अगली TC39 बैठक में प्रस्ताव की संभावनाओं को बेहतर बनाने का प्रयास करने के लिए ऑफ़लाइन काम करेंगे क्योंकि हम वास्तव में इसे भी पूरा करना चाहते हैं।

अपडेट: हम आज दोपहर TC39 पर स्टेज 2 पर पहुँचे !!!

वैकल्पिक श्रृंखला चरण 3 है

केवल जश्न मनाने के लिए इसे संक्षेप में अनलॉक करना

हुर्रे!

स्पैम न करें...

आप अपनी भावनाओं को व्यक्त करने वाला इमोजी भेज सकते हैं

स्पैम न करें...

आप अपनी भावनाओं को व्यक्त करने वाला इमोजी भेज सकते हैं

साथ ही, इमोजी काउंट को इस तरह चढ़ते हुए देखना मज़ेदार है। मैंने कभी किसी मुद्दे को इतनी तेजी से इतनी लोकप्रियता हासिल करते हुए नहीं देखा!

मैंने रीयल-टाइम अपडेट का एक छोटा सा वीडियो रिकॉर्ड किया है https://youtu.be/JLBrgPjeGhc

क्या कोई मुझे इस चीज़ से अनसब्सक्राइब कर सकता है?

@DanielRosenwasser यदि आप मज़ाक नहीं कर रहे हैं, या किसी और के लिए जो सदस्यता समाप्त करना चाहता है और नहीं जानता कि कैसे, आप दाहिने साइडबार में इस बटन की तलाश कर रहे हैं:

उल्लेख नहीं है कि ईमेल में एक लिंक है:

_{यह एक मजाक था, मैं प्रस्ताव पर काम कर रहा हूं।}

@RyanCavanaugh इस मुद्दे को अनलॉक करने के बाद:

यह अंत में जमीन देखने के लिए वास्तव में उत्साहित! मैं

मेल खाने वाले VSCode के त्वरित सुधार की प्रतीक्षा नहीं कर सकता

मैं @RyanCavanaugh जा रहा हूं क्योंकि वह शायद इस धागे की सदस्यता समाप्त कर चुका है और मैं कठोर होना चाहता हूं! (और @DanielRosenwasser अच्छे उपाय के लिए)

@kitsonk गधे मत बनो। लोग सदस्यता समाप्त करने और परेशान होने के लिए स्वतंत्र हैं।

@kitsonk , रयान कैवनुघ या डैनियल रोसेनवासर को इस धागे की सदस्यता क्यों नहीं दी जाएगी? रयान ने इस मुद्दे को अनलॉक किया और डैनियल ने आपके ऊपर तीन टिप्पणियों का जवाब दिया।

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

जाहिरा तौर पर GitHub व्यंग्यात्मक हास्य के लिए एक भयानक जगह है, जी ...

इस नई भाषा सुविधा के घटिया विवरण का पता लगाने के लिए TC39 में हमारे चैंपियन का बहुत-बहुत धन्यवाद!

मुझे लगता है कि @kitsonk बस मजाक कर रहा था, जैसे मैं था। जबकि हम उत्तेजना के इर्द-गिर्द थोड़े मूर्ख हैं, यह सीओसी के अनुसार चीजों को सभ्य रखने के लिए एक सौम्य अनुस्मारक है।

@DanielRosenwasser
क्या मुझे इस पर प्रयास करना पड़ सकता है? या @rbuckton के पास इसके लिए एक और शाखा मौजूद है ‍♂️

ठीक है मुझे मिल गया https://github.com/microsoft/TypeScript/commits/OptionalChainingStage1 🤦🏻‍♂️

हाँ, यह काफी पुराना है, दुर्भाग्य से।

मुझे अभी एहसास हुआ है कि यह मुद्दा 5 साल पहले खोला गया है। :आश्चर्यचकित:

@rbuckton

हाँ, यह काफी पुराना है, दुर्भाग्य से।

क्या मैं इस पर एक कोशिश कर सकता हूं?

क्षमा करें @jhpratt @MatthiasKunnen मैं भूल गया कि हम सभी GitHub पर समान संदर्भ साझा नहीं करते हैं। मैं लंबे समय से इधर-उधर उछल रहा हूं और रयान और डैनियल आईआरएल के साथ समय बिताया है और हाल के कार्यक्रम में संक्षेप में भाग लिया जिसने मजाक के अंदर मेरी गलतफहमी को जन्म दिया। क्षमा याचना।

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

जबकि @RyanCavanaugh इसे संबोधित कर सकते हैं, और मुझे पता है कि वह प्रस्ताव के साथ जो हुआ है, उसके करीब रहा है, मुझे संदेह है कि यह संभावना नहीं होगी कि 2014 में टीम ने जो वापस लागू किया होगा वह वर्तमान चरण 3 प्रस्ताव के साथ 100% संगत होगा। . इसलिए जब यह निश्चित रूप से एक उत्सव है, तो यह भी आभारी रहें कि हमारे पास 5 साल का टाइपस्क्रिप्ट कोड नहीं है जो एक सुरक्षित नेविगेशन ऑपरेटर के साथ है जो प्रस्ताव में व्यवहार के अनुरूप नहीं होगा।

🙏

क्या यह वेटिंग फॉर TC39 लेबल को हटाने का समय है? मैं

क्या यह वेटिंग फॉर TC39 लेबल को हटाने का समय है? मैं

और ship-it . जोड़ें

वाह

आखिरकार। सचमुच वैकल्पिक चेनिंग y'day के बारे में पूछ रहा था, सोच रहा था कि यह चरण 3 कब होगा, और बम! उन सभी को धन्यवाद जो इसे आगे बढ़ाने के लिए काम कर रहे थे!

इस धागे को कैसे म्यूट करें? :)

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

कोई उत्सर्जन समाधान पहले से ही परिभाषित है?
ऐसा कुछ दिलचस्प हो सकता है:

function __chain<T extends object, U>(value: T|null|undefined, callback: (value: T) => U): U|undefined {
    if (value !== null && value !== undefined) {
        return callback(value);
    }

    return undefined;
}

type Foo = { x?: { y?: { z?: () => number } } }

const foo: Foo|null = { }

// foo?.x?.y?.z?()
const value = __chain(foo, _a => __chain(_a.x, _b => __chain(_b.y, _c => __chain(_c.z, _d => _d()))));

मैं पसंद करता हूं कि बेबेल क्या करता है क्योंकि यह अनावश्यक फ़ंक्शन स्कोप बनाने से बचता है:

var _foo, _foo$x, _foo$x$y, _foo$x$y$z;

// foo?.x?.y?.z?.()
(_foo = foo) === null || _foo === void 0 ? void 0
    : (_foo$x = _foo.x) === null || _foo$x === void 0 ? void 0
    : (_foo$x$y = _foo$x.y) === null || _foo$x$y === void 0 ? void 0
    : (_foo$x$y$z = _foo$x$y.z) === null || _foo$x$y$z === void 0 ? void 0
    : _foo$x$y$z.call(_foo$x$y);

मैं पसंद करता हूं कि बेबेल क्या करता है क्योंकि यह अनावश्यक फ़ंक्शन स्कोप बनाने से बचता है:

var _foo, _foo$x, _foo$x$y, _foo$x$y$z;

// foo?.x?.y?.z?.()
(_foo = foo) === null || _foo === void 0 ? void 0
  : (_foo$x = _foo.x) === null || _foo$x === void 0 ? void 0
  : (_foo$x$y = _foo$x.y) === null || _foo$x$y === void 0 ? void 0
  : (_foo$x$y$z = _foo$x$y.z) === null || _foo$x$y$z === void 0 ? void 0
  : _foo$x$y$z.call(_foo$x$y);

मैं सहमत हूं, @ एक्सई-बॉस। मुझे लगता है कि अनावश्यक फ़ंक्शन स्कोप बनाने से बचना आदर्श है (भले ही यह संकलित कोड को थोड़ा बदसूरत बना दे)

जब हम संकलित कोड के बारे में बात कर रहे हों तो ES विनिर्देशन का प्रदर्शन और पालन निश्चित रूप से पठनीयता पर जीत हासिल करना चाहिए।

क्या कोई कारण है कि बेबेल द्वारा संकलित कोड null और void 0 दोनों की तुलना एक साधारण == null के बजाय ट्रिपल बराबर के साथ करता है?

क्या कोई कारण है कि बेबेल द्वारा संकलित कोड null और void 0 दोनों की तुलना एक साधारण == null के बजाय ट्रिपल बराबर के साथ करता है?

@proteria मैंने __Babel__ के लिए वैकल्पिक चेनिंग कोड पर एक त्वरित नज़र डाली; ऐसा लगता है कि यदि आप loose विकल्प में पास होते हैं और इसे एक सत्य मान पर सेट करते हैं, तो यह सख्त समानता जांच नहीं करता है

यह document.all (या पांडित्य के लिए, [[IsHTMLDDA]] आंतरिक स्लॉट ) के कारण है, एक विचित्रता जिसे पश्च संगतता के लिए भाषा में विशेष उपचार मिलता है।

document.all == null // true
document.all === null || document.all === undefined // false

वैकल्पिक श्रृखंला प्रस्ताव में

document.all?.foo === document.all.foo

लेकिन document.all == null ? void 0 : document.all.foo गलत तरीके से void 0 लौटाएगा। ढीले मोड में, कल्पना के इस विवरण को सादगी/प्रदर्शन/जनरेटेड कोड आकार के लिए खारिज कर दिया जाता है क्योंकि अधिकांश लोगों को वैसे भी document.all से निपटने की आवश्यकता नहीं होती है।

निश्चित रूप से document.all मामला विशेष हो सकता है? वस्तु और संपत्ति की जांच के लिए इसे अधिक अतिरिक्त कोड की आवश्यकता नहीं है, बस कुछ पंक्तियों की आवश्यकता है।

सिवाय इसके कि document.all को एक चर को सौंपा जा सकता है, और जहां इसका उपयोग किया जाता है वहां ट्रैकिंग के लिए एक प्रकार की प्रणाली की आवश्यकता होती है, यही कारण है कि बैबेल डिफ़ॉल्ट रूप से आउटपुट करता है:

(_prop = prop) === null || _prop === void 0 ? void 0 : _prop./* do stuff */;

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

वास्तव में, आपको document.all चर को ट्रैक करने के लिए एक प्रकार की प्रणाली की आवश्यकता नहीं है, क्योंकि विशेष व्यवहार वास्तव में HTMLAllCollection पर है, न कि document.all पर।

तो आपको बस instanceof HTMLAllCollection चेक करने में सक्षम होना चाहिए, और आप सुनहरे हो जाएंगे।

हाँ लेकिन... आपने instanceof क्यों किया जबकि आप केवल === null || === void 0 कर सकते हैं? निश्चित रूप से यह अधिक सरल है।

निश्चित रूप से - मैं सिर्फ यह इंगित कर रहा था कि आपको document.all को ट्रैक करने के लिए एक प्रकार की प्रणाली की आवश्यकता नहीं है :)

व्यक्तिगत रूप से मैं यह कहने के लिए ललचाता हूं कि इसे तोड़ दें और देखें कि कौन शिकायत करता है, लेकिन यह कल्पना में है, बस इसके साथ रहना इतना आसान है।

@noppa इसे संकलन समय पर किया जा सकता है। यदि foo instanceof HTMLAllCollection true है, तो foo === null || foo === void 0 उत्सर्जित करें, अन्यथा हम _safely_ foo == null उत्सर्जित कर सकते हैं।

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

@jhpratt लेकिन यह वर्तमान में टाइपस्क्रिप्ट डिज़ाइन गैर-लक्ष्य के विरुद्ध है।

साथ ही, आपको किसी भी चीज़ के लिए foo === null || foo === void 0 करना होगा जिसके लिए HTMLAllCollection असाइन किया जा सकता है, उदाहरण के लिए। any या object , इसलिए मुझे नहीं लगता कि यह वास्तव में इसके लायक है।

मुझे लगता है कि आप गैर-लक्ष्य (5) की बात कर रहे हैं

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

हालांकि मैं मानता हूं कि यह निश्चित रूप से प्रकार के आधार पर अलग-अलग कोड उत्सर्जित करेगा, यह केवल कोड आकार को कम करने के लिए है। हालांकि जैसा कि आपने बताया है, यह HTMLAllCollection की जांच करने जितना आसान नहीं है।

निष्पक्ष होने के लिए, TS _has_ ने एक संभावित मिनीफायर को खारिज कर दिया जो प्रकार की जानकारी का उपयोग करता है, और यह (प्रकार) संबंधित है - == null उत्सर्जित करने का प्राथमिक कारण प्रकार की जानकारी के आधार पर कोड आकार को कम करना है।

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

शीघ्रता से जाँच करने के बाद, terser स्वचालित रूप से foo === null || foo === undefined को foo == null में बदल देता है, जो इस एज केस के कारण सुरक्षित नहीं है।

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

संबंधित रूप से, हम में से कई लोग टाइपस्क्रिप्ट का उपयोग टूल बनाने और मोबाइल एप्लिकेशन के लिए करते हैं, जिनमें से किसी को भी ब्राउज़र बाधाओं के बारे में चिंता करने की ज़रूरत नहीं है!

वास्तव में, हम TS और Babel दोनों का एक साथ उपयोग करते हैं, इसलिए हो सकता है कि इनमें से एक विकल्प ऑपरेटर को Babel/अंतर्निहित रनटाइम पर पासथ्रू करना हो!

@fbartho

वास्तव में, हम TS और Babel दोनों का एक साथ उपयोग करते हैं, इसलिए हो सकता है कि इनमें से एक विकल्प ऑपरेटर को Babel/अंतर्निहित रनटाइम पर पासथ्रू करना हो!

मुझे यह टिप्पणी समझ में नहीं आ रही है। ऑपरेटर को बैबेल तक पहुंचाने के लिए आपको किसी अतिरिक्त विकल्प की आवश्यकता नहीं है; यदि आपके पास बैबेल के लिए टाइपस्क्रिप्ट सेट अप है, तो आपके पास पहले से ही noEmit: true है जो पहले से ही _everything_ से होकर बैबेल तक जाता है।

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

इस धागे पर आने वाले लोगों को पहले चरण 3 की घोषणा से शुरू करना चाहिए और वहां से शुरू होने वाली टिप्पणियों को पढ़ना चाहिए (सब कुछ लोड करने के लिए कोई सीधा तरीका नहीं होने के साथ उपयोगकर्ता सामग्री के टन को छिपाने के लिए गिटहब को दोष दें)

महान विशेषता - "वैकल्पिक श्रृखंला" / "सुरक्षित नेविगेशन"। विशेष रूप से टाइपस्क्रिप्ट सख्त-मोड में। यह जानकर बहुत अच्छा लगा कि इसे जल्द ही लागू किया जाएगा। ❤️

यह मुझे यहां लाया और मुझे आशा है कि इसका समर्थन किया जाएगा। बस एक उपयोग का मामला:

टाइपस्क्रिप्ट 3.7 में अपेक्षित।

document.querySelector('html')?.setAttribute('lang', 'en');

बनाम

वर्तमान में टाइपस्क्रिप्ट 3.5 में।

const htmlElement = document.querySelector('html');
if (htmlElement) {
  htmlElement.setAttribute('lang', 'en');
}

क्या यह बिना किसी त्रुटि के काम करेगा? या यह अभी भी TypeError: Cannot read property 'setAttribute' of null. है? ? सेशन। शून्य/अपरिभाषित के बाद आगे की श्रृंखला रद्द कर दी जानी चाहिए।

class Test {
  it() {
    console.log('One');
    document.querySelector('html')?.setAttribute('lang', 'en');
    console.log('Two');
  }
}
new Test().it();

मैं निम्नलिखित की अपेक्षा करता हूं:
यदि html तत्व मौजूद नहीं है (शून्य)। कंसोल को One और Two लॉग किया जाना चाहिए, और setAttribute विधि को लागू करने का प्रयास नहीं किया गया है। (त्रुटियाँ नहीं)।
क्या मैंने इसे सही ढंग से समझा?

@domske FYI करें, यह कड़ाई से TS सुविधा नहीं है; यह एक जेएस सुविधा है।

TC39 प्रस्ताव के अनुसार वाक्य रचना होगी:

document.querySelector('html')?.setAttribute?.('lang', 'en');

चर्चा फिर से सर्कुलर होने लगी है इसलिए हम वापस बंद स्थिति में आ गए हैं।

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