🏅 📘 🛌🏽 पुस्तक "{आप जेएस को नहीं जानते हैं} प्रकार और व्याकरण निर्माण" 🧜🏾 👩🏽‍🏫 ⬅️

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

"यू आर डोंट नो जेएस" श्रृंखला की अन्य पुस्तकों की तरह, यह भाषा के गैर-तुच्छ पहलुओं को दिखाता है जिसे जावास्क्रिप्ट प्रोग्रामर दूर रहना पसंद करते हैं (या यह मान लें कि वे मौजूद नहीं हैं)। इस ज्ञान के साथ सशस्त्र, आप सच जावास्क्रिप्ट महारत हासिल करेंगे।

अंश। समानता सख्त और गैर सख्त है।

गैर-सख्त समानता == ऑपरेटर द्वारा जाँच की जाती है, और === ऑपरेटर द्वारा सख्त समानता। दोनों ऑपरेटरों का उपयोग "समानता" के लिए दो मूल्यों की तुलना करने के लिए किया जाता है, लेकिन फॉर्म का विकल्प (सख्त / गैर-सख्त) व्यवहार में बहुत महत्वपूर्ण अंतर की ओर जाता है, विशेषकर यह कि समानता पर निर्णय कैसे किया जाता है।

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

सही वर्णन है: "== समानता की जाँच करते समय टाइप रूपांतरण की अनुमति देता है, और === टाइप रूपांतरण पर रोक लगाता है।"

समानता सत्यापन प्रदर्शन

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

दूसरे स्पष्टीकरण में, == ऑपरेटर अधिक काम करता है, क्योंकि विभिन्न प्रकारों के साथ इसे टाइप रूपांतरण के माध्यम से जाना पड़ता है।

उस जाल में मत पड़ो, जिसमें कई गिर जाएं। ऐसा मत सोचो कि यह किसी भी तरह कार्यक्रम की गति को प्रभावित करेगा, और == किसी भी काफी धीमी === होगा। हालाँकि रूपांतरण में कुछ समय लगता है, लेकिन यह माइक्रोसेकंड (हाँ, एक सेकंड के मिलियन) में बात करता है।

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

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

यदि आपको रूपांतरण की आवश्यकता है, तो गैर-सख्त समानता == का उपयोग करें, और यदि रूपांतरण अवांछनीय है, तो सख्त समानता === का उपयोग करें।

दोनों ऑपरेटर, == और ===, अपने ऑपरेंड के प्रकारों की जाँच करते हैं। अंतर यह है कि वे किस प्रकार बेमेल का जवाब देते हैं।

सार समानता जाँच

== ऑपरेटर के व्यवहार को ES5 विनिर्देश ("सार समानता परीक्षक एल्गोरिथम") की धारा 11.9.3 में परिभाषित किया गया है। यहां एक विस्तृत लेकिन सरल एल्गोरिथ्म है, जिसमें सभी प्रकार के संभावित संयोजन और प्रकार रूपांतरण विधियों (यदि आवश्यक हो) की स्पष्ट सूची है, जिसे प्रत्येक संयोजन में लागू किया जाना चाहिए।

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

मेरा मानना है कि यह एक गलत धारणा है - आप पाठक सक्षम डेवलपर हैं जो दिन भर एल्गोरिदम लिखते हैं, यानी कोड (और इसे पढ़ते और समझते भी हैं)। इस कारण से, मैं "सार समानता परीक्षण" को सरल शब्दों में समझाने की कोशिश करूंगा। हालाँकि, मैं ES5 विनिर्देश के खंड 11.9.3 को पढ़ने की भी सलाह देता हूँ। मुझे लगता है कि यह आपको आश्चर्यचकित करेगा कि सब कुछ कितना तार्किक है।

वास्तव में, पहला खंड (11.9.3.1) बताता है कि यदि दो तुलनात्मक मान एक ही प्रकार के हैं, तो उनकी तुलना सरल और प्राकृतिक तरीके से की जाती है। उदाहरण के लिए, 42 केवल 42 है, और स्ट्रिंग "एबीसी" केवल "एबीसी" है।

कुछ मामूली अपवादों को ध्यान में रखना:

NaN का मान कभी भी अपने आप में बराबर नहीं होता (देखें अध्याय 2)।
+0 और -0 एक दूसरे के बराबर हैं (अध्याय 2 देखें)।

धारा 11.9.3.1 में अंतिम खंड वस्तुओं के साथ == (कार्यों और सरणियों सहित) की एक कठोर परीक्षा के लिए समर्पित है। इस तरह के दो मूल्य समान हैं, यदि दोनों बिल्कुल समान मूल्य को संदर्भित करते हैं। किसी प्रकार का रूपांतरण नहीं किया जाता है।

एक सख्त समानता की जांच === को दो वस्तु मानों के प्रावधान सहित, 11.9.3.1 पर समान रूप से परिभाषित किया गया है। यह तथ्य बहुत कम ज्ञात है, लेकिन == और === दो वस्तुओं की तुलना करते समय पूरी तरह समान व्यवहार करते हैं!

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

असमानता की कमजोर जाँच का संचालन! वास्तव में, ऑपरेशन == पूरी तरह से लागू किया गया है, गणना के बाद
परिणाम का खंडन। समान रूप से असमानता की जांच करने के संचालन पर लागू होता है! ==।

तुलना: तार और संख्या

== के रूपांतरण को प्रदर्शित करने के लिए, पहले स्ट्रिंग्स और संख्याओं के उदाहरण बनाएं, जो पहले इस अध्याय में किया गया था:

var a = 42; var b = "42"; a === b; // false a == b; // true

जैसा कि अपेक्षित था, एक === b चेक विफल हो जाता है क्योंकि रूपांतरण की अनुमति नहीं है, और मान 42 और "42" भिन्न हैं।

हालांकि, दूसरी तुलना में == बी, गैर-सख्त समानता का उपयोग किया जाता है; इसका मतलब यह है कि यदि प्रकार भिन्न हैं, तो तुलना एल्गोरिथ्म एक के एक अंतर्निहित रूपांतरण का प्रदर्शन करेगा
या दोनों।

लेकिन यहां किस तरह का रूपांतरण किया जा रहा है? क्या मान a, यानी 42, एक स्ट्रिंग बन जाएगा, या मान b "42" एक संख्या बन जाएगा? ES5 विनिर्देश 11.9.3.4-4 सेक्शन में है:

यदि टाइप (x) टाइप नंबर का है, और टाइप (y) टाइप स्ट्रिंग का है, तो तुलना x == ToNumber (y) का परिणाम लौटाएं।
यदि टाइप (x) टाइप स्ट्रिंग का है और टाइप (y) टाइप नंबर का है, तो तुलना का परिणाम लौटाएं ToNumber (x) == y।

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

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

तुलना: बूलियन के साथ कुछ भी

प्रकार के निहितार्थ में सबसे खतरनाक जालों में से एक == का सामना तब किया जाता है जब सही या गलत के साथ मूल्यों की तुलना करने की कोशिश की जाती है।

एक उदाहरण:

 var a = "42"; var b = true; a == b; // false

रुको, यहाँ क्या हो रहा है? हम जानते हैं कि "42" सही अर्थ है (पहले इस अध्याय में देखें)। यह कैसे पता चलता है कि सख्त समानता == के बयान के साथ इसकी तुलना करना सही है
सच नहीं देता?

कारण एक ही समय में सरल और भ्रामक रूप से चालाक है। गलत समझना आसान है, कई जेएस डेवलपर्स इसे पूरी तरह से समझने का प्रयास नहीं करते हैं।

एक बार फिर हम विनिर्देश को उद्धृत करते हैं, खंड 11.9.3.6–7:

यदि प्रकार (x) प्रकार बूलियन का है, तो तुलना के परिणाम को वापस करें ToNumber (x) == y।
यदि टाइप (y) बुलियन का है, तो तुलना x == ToNumber (y) का परिणाम लौटाएं।

आइए देखें कि यहां क्या है। पहला कदम:

 var x = true; var y = "42"; x == y; // false

प्रकार (x) वास्तव में बूलियन प्रकार से संबंधित है, इसलिए ToNumber (x) ऑपरेशन किया जाता है, जो 1. 1 पर सही रूप से परिवर्तित होता है। अब 1 == "42" की गणना की जाती है। प्रकार अभी भी भिन्न हैं, इसलिए (लगभग पुनरावर्ती) एल्गोरिथ्म दोहराता है; पिछले मामले में, "42" को 42 में बदला गया है, और हालत 1 == 42 स्पष्ट रूप से गलत है।

यदि आप ऑपरेंड स्वैप करते हैं, तो परिणाम समान रहेगा:

 var x = "42"; var y = false; x == y; // false

इस बार, टाइप (y) प्रकार बूलियन का है, इसलिए ToNumber (y) 0. देता है "शर्त" 42 "== 0 पुनरावर्ती रूप से 42 == 0 में बदल जाती है, जो निश्चित रूप से गलत है।

दूसरे शब्दों में, "42" का मान न तो == सच है और न ही = गलत है। पहली नज़र में, यह कथन पूरी तरह से अकल्पनीय लगता है। कैसे अर्थ न तो सही हो सकता है और न ही गलत?

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

मूल्य "42" वास्तव में सच है, लेकिन निर्माण "42" == सच आपके मस्तिष्क जो भी कहता है, वह बिलियन / ट्रांसफॉर्म टेस्ट बिल्कुल भी नहीं करता है। "42" बूलियन में परिवर्तित नहीं होता (सच); इसके बजाय, सत्य 1 में बदल जाता है, और फिर "42" 42 में बदल जाता है।

आप इसे पसंद करते हैं या नहीं, यहाँ पर ToBoolean का उपयोग नहीं किया जाता है, इसलिए "42" की सच्चाई या झूठ = = ऑपरेशन के लिए बिल्कुल भी महत्वपूर्ण नहीं है! यह समझना महत्वपूर्ण है कि कैसे == तुलना एल्गोरिथ्म सभी विभिन्न प्रकार के संयोजनों में व्यवहार करता है। यदि बूलियन मूल्य एक तरफ है, तो इसे हमेशा पहले एक संख्या में बदल दिया जाता है।

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

लेकिन याद रखें कि मैं केवल == के बारे में यहां बात कर रहा हूं। निर्माण === सत्य और === असत्य प्रकार के रूपांतरण की अनुमति नहीं देते हैं, इसलिए वे छिपे हुए ToNumber रूपांतरण से सुरक्षित हैं।

एक उदाहरण:

 var a = "42"; //  (  !): if (a == true) { // .. } //   (  !): if (a === true) { // .. } //   ( ): if (a) { // .. } //  ( ): if (!!a) { // .. } //   ( ): if (Boolean( a )) { // .. }

यदि आप अपने कोड में == सच या == झूठी (बूलियन के साथ ढीली समानता) से बचते हैं, तो आपको इस सच्चाई / झूठ के जाल के बारे में चिंता करने की आवश्यकता नहीं होगी।

तुलना: अपरिभाषित के साथ अशक्त

निहित रूपांतरण का एक और उदाहरण तब होता है जब आप अशक्त और अपरिभाषित मूल्यों के बीच लक्स == समानता का उपयोग करते हैं। फिर, मैं ES5 विनिर्देश उद्धृत करूंगा,
अनुभाग 11.9.3.2–3:

यदि x में null है और y में अपरिभाषित है, तो सही लौटें।
यदि x में अपरिभाषित है और y में अशक्त है, तो सही लौटें।

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

हमारे लिए, इसका मतलब है कि अशक्त और अपरिभाषित को तुलनात्मक उद्देश्यों के लिए अप्रभेद्य माना जा सकता है, यदि आप गैर-सख्त समानता परीक्षण ऑपरेटर == का उपयोग करते हैं, तो उनके पारस्परिक निहितार्थ की अनुमति देता है:

 var a = null; var b; a == b; // true a == null; // true b == null; // true a == false; // false b == false; // false a == ""; // false b == ""; // false a == 0; // false b == 0; // false

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

एक उदाहरण:

 var a = doSomething(); if (a == null) { // .. }

A == null चेक केवल तभी पास होता है यदि doSomething () null या अनिर्धारित रिटर्न देता है और किसी भी अन्य मान के लिए विफल रहता है (0, झूठा और "" सहित)।

इस जाँच का स्पष्ट रूप, जो किसी भी प्रकार के रूपांतरणों पर रोक लगाता है, लगता है (मेरी राय में) बहुत बदसूरत है और बहुत कम कुशलता से काम कर सकता है!

 var a = doSomething(); if (a === undefined || a === null) { // .. }

मेरा मानना है कि फॉर्म == नल एक ऐसी स्थिति का एक और उदाहरण है जिसमें एक अंतर्निहित रूपांतरण से कोड को पढ़ना आसान हो जाता है, लेकिन क्या यह विश्वसनीय और सुरक्षित रूप से होता है।

तुलना: वस्तु और गैर-वस्तु

यदि किसी ऑब्जेक्ट / फ़ंक्शन / सरणी की तुलना एक साधारण स्केलर आदिम (स्ट्रिंग, संख्या या बूलियन) के साथ की जाती है, तो ES5 विनिर्देश निम्नलिखित कहता है (अनुभाग 11.9.3.8-9):

यदि टाइप (x) टाइप स्ट्रिंग या संख्या का है, और Type (y) टाइप ऑब्जेक्ट का है, तो तुलना x == ToPrimitive (y) का परिणाम लौटाएं।
यदि प्रकार (x) प्रकार वस्तु का है और प्रकार (y) प्रकार स्ट्रिंग या संख्या का है, तो तुलनात्मक परिणाम के परिणाम को वापस लाएं (x) == y।

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

एक उदाहरण:

 var a = 42; var b = [ 42 ]; a == b; // true

मान [42] के लिए, अमूर्त ऑपरेशन ToPrimitive कहा जाता है ("सार संचालन" देखें), जो "42" परिणाम देता है। इस क्षण से, साधारण स्थिति "42" == 42 बनी हुई है, जो, जैसा कि हम पहले ही पता लगा चुके हैं, 42 == 42 में बदल जाती है, ताकि ए और बी टाइप रूपांतरण के बराबर हो।

जैसा कि आप उम्मीद करेंगे, इस अध्याय में (पहले (toString) (), valueOf ()) अमूर्त ToPrimitive ऑपरेशन की सभी विशेषताएं इस मामले में भी लागू हैं। यदि आपके पास एक जटिल डेटा संरचना है और चाहते हैं तो यह बहुत उपयोगी हो सकता है। इसके लिए एक विशेष विधि valueOf () परिभाषित करें, जिसे समानता की जाँच के प्रयोजनों के लिए एक सरल मूल्य प्रदान करना होगा।

अध्याय 3 ने एक आदिम मूल्य के आसपास एक वस्तु आवरण के "अनपैकिंग" की जांच की (जैसा कि नए स्ट्रिंग ("एबीसी") में, उदाहरण के लिए), जिसके परिणामस्वरूप अंतर्निहित आदिम की वापसी होती है।
मूल्य ("एबीसी")। यह व्यवहार == एल्गोरिथ्म में ToPrimitive परिवर्तन से संबंधित है:

 var a = "abc"; var b = Object( a ); //  ,  `new String( a )` a === b; // false a == b; // true

a == b सही देता है क्योंकि आधार सरल स्केलर आदिम मान "abc" के लिए ToPrimitive ऑपरेशन द्वारा b परिवर्तित (या "अनपैक्ड") है, जो a से मान से मेल खाता है।

कुछ मूल्य हैं जिनके लिए == एल्गोरिथ्म में अन्य ओवरराइडिंग नियमों के कारण ऐसा नहीं है। एक उदाहरण:

 var a = null; var b = Object( a ); //  ,  `Object()` a == b; // false var c = undefined; var d = Object( c ); //  ,  `Object()` c == d; // false var e = NaN; var f = Object( e ); //  ,  `new Number( e )` e == f; // false

अशक्त और अपरिभाषित मानों को पैक नहीं किया जा सकता है (उनके पास समतुल्य वस्तु आवरण नहीं है), इसलिए ऑब्जेक्ट (नल) वस्तु से मूलभूत रूप से भिन्न नहीं है (): दोनों कॉल सामान्य रूप से बनाते हैं
ny वस्तु।

NaN को बराबर संख्या ऑब्जेक्ट रैपर में पैक किया जा सकता है, लेकिन जब == अनपैकिंग का कारण बनता है, तो NaN == NaN तुलना विफल हो जाती है क्योंकि NaN मान कभी भी स्वयं के बराबर नहीं होता है (अध्याय 2 देखें)।

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

फेरीवालों के लिए कूपन पर 25% की छूट - जावास्क्रिप्ट

पुस्तक के पेपर संस्करण के भुगतान पर, एक इलेक्ट्रॉनिक पुस्तक ई-मेल द्वारा भेजी जाती है।

पुस्तक "{आप जेएस को नहीं जानते हैं} प्रकार और व्याकरण निर्माण"