जावास्क्रिप्ट में == का उपयोग करना कभी मायने रखता है?


276

में जावास्क्रिप्ट, अच्छा पार्ट्स , डगलस Crockford लिखा है:

जावास्क्रिप्ट में समानता ऑपरेटरों के दो सेट हैं: ===और !==, और उनके दुष्ट जुड़वां ==और !=। अच्छे लोग उस तरह से काम करते हैं जिस तरह से आप उम्मीद करते हैं। यदि दो ऑपरेंड एक ही प्रकार के हैं और एक ही मूल्य हैं, तो ===उत्पादन trueऔर !==उत्पादन करता है false। जब आप एक ही प्रकार के होते हैं, तो दुष्ट जुड़वाँ सही काम करते हैं, लेकिन अगर वे अलग-अलग प्रकार के होते हैं, तो वे मूल्यों के साथ छेड़छाड़ करने का प्रयास करते हैं। वे जिस नियम से करते हैं वह जटिल और अमंगल है। ये कुछ दिलचस्प मामले हैं:

'' == '0'           // false
0 == ''             // true
0 == '0'            // true

false == 'false'    // false
false == '0'        // true

false == undefined  // false
false == null       // false
null == undefined   // true

' \t\r\n ' == 0     // true

परिवर्तनशीलता की कमी चिंताजनक है। मेरी सलाह है कि कभी भी दुष्ट जुड़वां बच्चों का उपयोग न करें। इसके बजाय, हमेशा उपयोग करें ===और !==। सभी तुलना बस ऑपरेटर के falseसाथ उत्पादन दिखाया ===

इस अप्रतिम अवलोकन को देखते हुए, क्या कभी ऐसा समय आता है जब ==वास्तव में उपयुक्त हो सकता है?


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

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

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

5
एक जगह जिसका मैं उपयोग करता हूं == यह है कि ड्रॉपडाउन आईडी (जो हमेशा चार है) की तुलना मॉडल आईडी के लिए (जो आमतौर पर इंट) हैं।
स्कूटी

11
@DevSolar वेब विकास तब समझ में आता है जब आप 15 प्लेटफार्मों में से प्रत्येक के लिए एक देशी ऐप के उत्पादन के साथ-साथ एक प्लेटफॉर्म के एकाधिकार ऐप स्टोर पर प्रमाणीकरण के साथ सौदा नहीं करना चाहते हैं।
दामियन येरिक

जवाबों:


232

मैं एक तर्क करने जा रहा हूं ==

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

जावास्क्रिप्ट एक व्यवहारिक रूप से * टाइप की गई भाषा है। चीजों का इलाज इस आधार पर किया जाता है कि वे क्या कर सकते हैं और उनका वास्तविक प्रकार नहीं। यही कारण है कि आप एक सरणी .mapविधि को नोडलिस्ट या एक jQuery चयन सेट पर कॉल कर सकते हैं । यह भी है कि आप ऐसा क्यों कर सकते हैं 3 - "5"और कुछ सार्थक प्राप्त कर सकते हैं - क्योंकि "5" एक संख्या की तरह कार्य कर सकता है।

जब आप एक ==समानता का प्रदर्शन करते हैं तो आप इसके प्रकार के बजाय एक चर की सामग्री की तुलना कर रहे हैं । यहां कुछ मामले हैं जहां यह उपयोगी है:

  • उपयोगकर्ता से एक संख्या पढ़ना - .valueडोम में एक इनपुट तत्व को पढ़ें ? कोई दिक्कत नहीं है! आपको इसे कास्टिंग शुरू करने या इसके प्रकार के बारे में चिंता करने की ज़रूरत नहीं है - आप ==इसे सही संख्या में कर सकते हैं और कुछ सार्थक वापस पा सकते हैं।
  • एक घोषित चर के "अस्तित्व" के लिए जाँच करने की आवश्यकता है? - आप == nullइसे तब से कर सकते हैं क्योंकि व्यवहारिक रूप से nullप्रतिनिधित्व करता है कि वहाँ कुछ भी नहीं है और अपरिभाषित वहाँ कुछ भी नहीं है।
  • यह जाँचने की आवश्यकता है कि क्या आपको किसी उपयोगकर्ता से सार्थक इनपुट मिला है? - जांच करें कि क्या इनपुट ==तर्क के साथ गलत है, यह उन मामलों का इलाज करेगा जहां उपयोगकर्ता ने आपके लिए कुछ भी नहीं किया है या केवल सफेद-स्थान दर्ज किया है, जो कि शायद आपकी जरूरत है।

आइए क्रॉकफोर्ड के उदाहरणों को देखें और उन्हें व्यवहारिक रूप से समझाएं:

'' == '0'           // got input from user vs. didn't get input - so false
0 == ''             // number representing empty and string representing empty - so true
0 == '0'            // these both behave as the number 0 when added to numbers - so true    
false == 'false'    // false vs got input from user which is truthy - so false
false == '0'        // both can substitute for 0 as numbers - so again true

false == undefined  // having nothing is not the same as having a false value - so false
false == null       // having empty is not the same as having a false value - so false
null == undefined   // both don't represent a value - so true

' \t\r\n ' == 0     // didn't get meaningful input from user vs falsey number - true 

मूल रूप से, जावास्क्रिप्ट में ==कैसे व्यवहार करते हैं, इसके आधार पर काम करने के लिए डिज़ाइन किया गया है जो वे नहीं हैं । हालांकि मैं व्यक्तिगत रूप से इस दृष्टिकोण से सहमत नहीं हूं, लेकिन ऐसा करने में निश्चित रूप से योग्यता है - खासकर यदि आप व्यवहार भाषा के आधार पर उपचार के इस प्रतिमान को लेते हैं।

* कुछ लोग संरचनात्मक टाइपिंग को पसंद कर सकते हैं जो कि अधिक सामान्य है लेकिन एक अंतर है - यहाँ अंतर पर चर्चा करने में वास्तव में दिलचस्पी नहीं है।


8
यह एक शानदार उत्तर है, और मैं आपके तीनों '==' मामलों का उपयोग करता हूं। # 1 & # 3 विशेष रूप से उपयोगी हैं।
क्रिस सिरफिस

223
इसके साथ समस्या ==यह नहीं है कि इसकी तुलना में कोई भी उपयोगी नहीं है , यह है कि नियमों को याद रखना असंभव है, इसलिए आपको गलतियों को करने की गारंटी है। उदाहरण के लिए: "यह जांचने की आवश्यकता है कि क्या आपको किसी उपयोगकर्ता से सार्थक इनपुट मिला है?", लेकिन '0' एक सार्थक इनपुट है और '0'==falseसत्य है। यदि आपने उपयोग किया ===होता तो आप स्पष्ट रूप से उस बारे में सोचते और आप गलती नहीं करते।
टिम्मम

44
"नियमों को याद रखना असंभव है" <== यह वह चीज़ है जो मुझे जावास्क्रिप्ट में "सार्थक" कुछ भी करने से डराता है। (और फ्लोट मैथ जो मूल कैल्क
एक्सर्साइज

9
3 - "5"उदाहरण अपने आप ही एक अच्छा बिंदु को जन्म देती है, भले ही आप केवल का उपयोग ===तुलना के लिए, कि अभी जिस तरह चर जावास्क्रिप्ट में काम करते हैं। इसे पूरी तरह से बचने का कोई तरीका नहीं है।
जरीट मिलार्ड

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

94

यह पता चला है कि jQuery निर्माण का उपयोग करता है

if (someObj == null) {
  // do something
}

समान रूप से, समतुल्य कोड के लिए शॉर्टहैंड के रूप में:

if ((someObj === undefined) || (someObj === null))  {
  // do something
}

यह ECMAScript लैंग्वेज स्पेसिफिकेशन .3 11.9.3 का परिणाम है, एब्सट्रैक्ट इक्वैलिटी कम्पेरिजन एलगोरिदम , जो बताता है, अन्य बातों के अलावा,

1.  If Type(x) is the same as Type(y), then  
    a.  If Type(x) is Undefined, return true.  
    b.  If Type(x) is Null, return true.

तथा

2.  If x is null and y is undefined, return true.
3.  If x is undefined and y is null, return true.

यह विशेष तकनीक आम है कि JSHint के पास विशेष रूप से इसके लिए डिज़ाइन किया गया एक ध्वज है।


10
आपके अपने प्रश्न का उत्तर देने वाला कोई भी निष्पक्ष व्यक्ति जो मैं इस बात का जवाब देना चाहता था :) == null or undefinedवह एकमात्र स्थान है जहाँ मैं उपयोग नहीं करता ===या!==
pl40

26
निष्पक्ष रूप से jQuery शायद ही एक मॉडल कोडबेस है। JQuery के स्रोत को कई बार पढ़ने के बाद, यह बहुत से नेस्टेड टर्नरी, अस्पष्ट बिट्स, नेस्टिंग और बहुत सी चीजों के साथ मेरे कम से कम पसंदीदा कोडबेस में से एक है जो मैं अन्यथा वास्तविक कोड में नहीं बचता। हालांकि इसके लिए मेरा शब्द न लें - इसे github.com/jquery/jquery/tree/master/src पर पढ़ें और फिर Zepto के साथ तुलना करें जो एक jQuery क्लोन है: github.com/madrobby/zepto-tree/master/src
बेंजामिन ग्रुएनबाम

4
यह भी ध्यान दें कि Zepto डिफ़ॉल्ट रूप से लगता है ==और केवल ===उन मामलों में उपयोग करता है जहां इसकी आवश्यकता होती है: github.com/madrobby/zepto/blob/master/src/event.js
Hey

2
@ उचित होने के लिए Zepto शायद ही एक मॉडल कोडबेस है - यह उपयोग करने के लिए बदनाम है __proto__और बदले में मोबाइल वेबसाइटों को तोड़ने से बचने के लिए भाषा विनिर्देश में लगभग एकल रूप से मजबूर करता है।
बेंजामिन ग्रुएनबाम

2
@BenjaminGruenbaum कि उनके कोडबेस की गुणवत्ता पर एक निर्णय कॉल नहीं था, केवल यह इंगित करते हुए कि विभिन्न परियोजनाएं विभिन्न सम्मेलनों का पालन करती हैं।
अरे

15

मूल्यों की जाँच करना nullया undefinedएक बात है, जैसा कि बहुतायत से समझाया गया है।

एक और बात है, जहां ==चमकता है:

आप तुलना को इस >=तरह से परिभाषित कर सकते हैं (लोग आमतौर से शुरू करते हैं >लेकिन मुझे यह अधिक सुरुचिपूर्ण लगता है):

  • a > b <=> a >= b && !(b >= a)
  • a == b <=> a >= b && b >= a
  • a < bऔर a <= bपाठक को एक अभ्यास के रूप में छोड़ दिया जाता है।

जैसा कि हम जानते हैं, जावास्क्रिप्ट "3" >= 3और "3" <= 3, जिसमें से आपको मिलता है 3 == "3"। आप एक बिंदु बना सकते हैं कि स्ट्रिंग को पार्स करके स्ट्रिंग्स और संख्याओं के बीच तुलना को लागू करने की अनुमति देना एक भयानक विचार है। लेकिन यह देखते हुए कि इस तरह से यह काम करता है, ==पूरी तरह से है कि रिश्ते ऑपरेटर लागू करने के लिए सही तरीका।

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

function compare(a, b) {
  if (a > b) return 1;
  if (a < b) return -1;
  return 0;
}

आप ==पहले से ही उपयोग कर रहे हैं ।

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

  • विशेषताएँ हमेशा तार होती हैं
  • चाबियां हमेशा तार होती हैं (उपयोग मामला यह है कि आप Objectइन्टर्स से वैल्यूज़ के लिए स्पार्स मैप का उपयोग करते हैं)
  • उपयोगकर्ता इनपुट और प्रपत्र नियंत्रण मूल्य हमेशा तार होते हैं (भले ही स्रोत मेल खाता हो input[type=number])

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


4
निष्पक्ष होना >=वास्तव में सकर्मक नहीं है। जेएस में यह काफी संभव है कि न तो a > bऔर a < bन ही b == a(उदाहरण के लिए:) NaN
बेंजामिन ग्रुएनबाम

8
@BenjaminGruenbaum: ऐसा कहना +वास्तव में सराहनीय नहीं है, क्योंकि NaN + 5 == NaN + 5यह पकड़ में नहीं आता है। मुद्दा यह है कि >=नंबर-ईश मानों के साथ ==काम करता है जिसके लिए लगातार काम करता है। यह आश्चर्य की बात नहीं है कि "नहीं एक नंबर" अपने स्वभाव से नहीं नंबर-ईश है;)
बैक

4
तो के खराब व्यवहार के खराब व्यवहार के ==अनुरूप है >=? बहुत अच्छा, अब मेरी इच्छा है कि एक >==...
एल्ड्रिच कॉनंड्रम

2
@EldritchConundrum: जैसा कि मैंने समझाने की कोशिश की है, का व्यवहार >=बाकी भाषा / एपीआई एपीआई के अनुरूप है। अपनी समग्रता में, जावास्क्रिप्ट इसके quirky भागों के योग से अधिक होने का प्रबंधन करता है। यदि आप चाहें >==, तो क्या आप भी एक सख्त +चाहते हैं? व्यवहार में, इन फैसलों से कई चीजें बहुत आसान हो जाती हैं। इसलिए मैं उन्हें गरीब समझने की जल्दी नहीं करता।
back2dos

2
@EldritchConundrum: फिर से: संबंध ऑपरेटर संख्यात्मक मानों की तुलना करने के लिए होते हैं, जहां एक ऑपरेंड वास्तव में एक स्ट्रिंग हो सकता है। ऑपरेंड प्रकारों के लिए जो >=सार्थक है, ==समान रूप से सार्थक है - बस इतना ही। कोई भी आप की तुलना करनी चाहिए कहते हैं [[]]के साथ false। C जैसी भाषाओं में बकवास के इस स्तर का परिणाम अपरिभाषित व्यवहार है। बस इसे उसी तरह से समझो: ऐसा मत करो। और तुम ठीक हो जाओगे। आपको जादू के किसी भी नियम को याद रखने की आवश्यकता नहीं होगी। और फिर यह वास्तव में बल्कि सीधे आगे है।
back2dos

8

एक पेशेवर गणितज्ञ के रूप में, मैं जावास्क्रिप्ट के सममित ऑपरेटर == ( जिसे "अमूर्त तुलना", "ढीली समानता" भी कहा जाता है ) को संस्थाओं के बीच एक समानता संबंध बनाने का प्रयास करता हूं , जिसमें रिफ्लेक्सिव , सममित और सकर्मक शामिल हैं । दुर्भाग्य से, इन तीन मौलिक गुणों में से दो असफल:

==प्रतिवर्त नहीं है :

A == A असत्य हो सकता है, उदा

NaN == NaN // false

==सकर्मक नहीं है :

A == Bऔर B == Cएक साथ मतलब नहीं है A == C, जैसे

'1' == 1 // true
1 == '01' // true
'1' == '01' // false

केवल सममित संपत्ति बच जाती है:

A == Bतात्पर्य B == A, जो उल्लंघन किसी भी मामले में संभवतया अकल्पनीय है और इससे गंभीर विद्रोह होगा;)

तुल्यता संबंध क्यों मायने रखता है?

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

==गैर-तुल्यता संबंध के लिए लिखना इतना भयानक विचार क्यों है ?

क्योंकि यह हमारी परिचितता और अंतर्ज्ञान को तोड़ता है, क्योंकि वस्तुतः समानता, समानता, अनुरूपता, समरूपता, पहचान आदि का कोई भी दिलचस्प संबंध एक समानता है।

रूपांतरण टाइप करें

सहज ज्ञान युक्त तुल्यता पर निर्भर होने के बजाय, जावास्क्रिप्ट प्रकार रूपांतरण शुरू करता है:

समानता ऑपरेटर ऑपरेंड्स को परिवर्तित करता है यदि वे एक ही प्रकार के नहीं हैं, तो सख्त तुलना लागू करता है।

लेकिन प्रकार रूपांतरण कैसे परिभाषित किया गया है? कई अपवादों के साथ जटिल नियमों का एक सेट है?

तुल्यता संबंध बनाने का प्रयास

बूलियन्स। स्पष्ट रूप से trueऔर falseसमान नहीं हैं और विभिन्न वर्गों में होना चाहिए।

नंबर। सौभाग्य से, संख्याओं की समानता पहले से ही अच्छी तरह से परिभाषित है, जिसमें दो अलग-अलग संख्याएं समान समानता वर्ग में कभी नहीं होती हैं। गणित में, वह है। जावास्क्रिप्ट में संख्या की धारणा कुछ अधिक विदेशी की उपस्थिति के माध्यम से विकृत है-0 , Infinityऔर -Infinity। हमारे गणितीय अंतर्ज्ञान तय है कि 0और -0एक ही कक्षा में होना चाहिए (वास्तव में -0 === 0है true), जबकि infinities से प्रत्येक एक अलग वर्ग है।

नंबर और बुलियन। संख्या वर्गों को देखते हुए, हम बूलियन कहां डालते हैं? falseके समान हो जाता है 0, जबकि दूसरी संख्या के trueसमान हो जाता है 1:

true == 1 // true
true == 2 // false

क्या यहाँ कोई तर्क है trueसाथ में रखने के लिए 1? विशेष रूप 1से प्रतिष्ठित है, लेकिन ऐसा है -1। मैं व्यक्तिगत रूप से परिवर्तित trueकरने का कोई कारण नहीं देखता हूं 1

और यह और भी बदतर हो जाता है:

true + 2 // 3
true - 1 // 0

तो trueवास्तव में 1सभी नंबरों में परिवर्तित हो गया है ! क्या यह तर्कसंगत है? क्या यह सहज है? जवाब व्यायाम के रूप में छोड़ दिया गया है;)

लेकिन इससे क्या:

1 && true // true
2 && true // true

होने के xसाथ एकमात्र बूलियन है । कौन सा साबित करता है कि दोनों और (और की तुलना में किसी अन्य नंबर ) में बदलने का ! यह दर्शाता है कि हमारा रूपांतरण एक अन्य महत्वपूर्ण संपत्ति - बायजेक्शन होने में विफल रहता है । मतलब कि दो अलग-अलग इकाइयाँ एक ही में बदल सकती हैं। जो, अपने आप से, एक बड़ी समस्या नहीं है। बड़ी समस्या तब पैदा होती है जब हम इस रूपांतरण का उपयोग "साम्यता" या "ढीली समानता" के संबंध का वर्णन करने के लिए करते हैं जो हम इसे कॉल करना चाहते हैं। लेकिन एक बात स्पष्ट है - यह एक समतुल्य संबंध नहीं होने जा रहा है और यह सहज रूप से समतुल्यता वर्गों के माध्यम से वर्णित नहीं होने जा रहा है।x && truetruex = true120true

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

कम से कम गणितीय रूप से - निश्चित रूप से हाँ! बूलियन और संख्याओं के बीच एक सरल तुल्यता का संबंध केवल falseऔर 0उसी वर्ग में होने के साथ निर्मित किया जा सकता है । तो false == 0केवल गैर-तुच्छ ढीली समानता होगी।

तार के बारे में क्या?

हम शुरुआत में और अंत में व्हाट्सएप से स्ट्रिंग्स को संख्याओं में बदलने के लिए ट्रिम कर सकते हैं, साथ ही हम सामने के शून्य को भी अनदेखा कर सकते हैं:

'   000 ' == 0 // true
'   0010 ' == 10 // true

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

इस तरह हम वास्तव में बूलियन, संख्या और तारों के कुल सेट पर एक परिपूर्ण तुल्यता संबंध प्राप्त कर सकते हैं! सिवाय इसके कि ... जावास्क्रिप्ट डिजाइनरों स्पष्ट रूप से एक और राय है:

' ' == '' // false

तो दो तार जो दोनों को परिवर्तित करते 0हैं वे अचानक गैर-समान हैं! क्यों या क्यों? नियम के अनुसार, स्ट्रिंग्स शिथिल समान रूप से ठीक होते हैं जब वे कड़ाई से बराबर होते हैं! जैसा कि हम देखते हैं, न केवल यह नियम परिवर्तनशीलता को तोड़ता है, बल्कि यह निरर्थक भी है! ==इसे दूसरे के साथ कड़ाई से समान बनाने के लिए एक और ऑपरेटर बनाने का क्या मतलब है ===?

निष्कर्ष

ढीले समानता ऑपरेटर ==बहुत उपयोगी हो सकते थे यदि यह कुछ मौलिक गणितीय कानूनों का पालन कर रहे थे। लेकिन जैसा कि यह दुख की बात है, इसकी उपयोगिता ग्रस्त है।


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

@SolomonUcko NaNबुरे नागरिक के रूप में कार्य करता है :-)। किसी भी तुल्यता तुलना, सहज या नहीं के लिए परिवर्तनशीलता को बरकरार रखा जा सकता है और होना चाहिए।
दिमित्री जैतसेव

7

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

for (var key in obj) {
    var some_number = foo(key, obj[key]);  // or whatever -- this is just an example
    if (key == some_number) {
        blah();
    }
}

मुझे लगता है कि तुलनात्मक रूप key == some_numberसे Number(key) === some_numberया इसके बजाय प्रदर्शन करना बहुत अधिक स्वाभाविक है key === String(some_number)


3

मैं आज एक बहुत उपयोगी अनुप्रयोग भर में चला गया। यदि आप गद्देदार संख्याओं की तुलना करना चाहते 01हैं, तो सामान्य पूर्णांक की तरह , ==ठीक काम करता है। उदाहरण के लिए:

'01' == 1 // true
'02' == 1 // false

यह आपको 0 को हटाकर पूर्णांक में परिवर्तित करने से बचाता है।


4
मुझे पूरा यकीन है कि ऐसा करने का 'सही' तरीका है '04'-0 === 4, या संभवतःparseInt('04', 10) === 4
रतबूम'

मुझे पता नहीं था कि आप ऐसा कर सकते हैं।
जॉन स्नो

7
बहुत सुना है।
जॉन स्नो

1
@ शालम या+'01' === 1
एरिक लैगरग्रेन 22

1
'011' == 011 // falseगैर-सख्त मोड में, और SyntaxError सख्त मोड में। :)
ब्रायन एस

3

मुझे पता है कि यह एक देर से जवाब है, लेकिन लगता है कि कुछ संभावित भ्रम के बारे में nullऔर undefined, जो आईएमएचओ ==बुराई करता है, और अधिक ताकि पारगमन की कमी, जो काफी खराब है। विचार करें:

p1.supervisor = 'Alice';
p2.supervisor = 'None';
p3.supervisor = null;
p4.supervisor = undefined;

इनका क्या मतलब है?

  • p1 एक पर्यवेक्षक है जिसका नाम "एलिस है।"
  • p2 एक पर्यवेक्षक है जिसका नाम "कोई नहीं" है।
  • p3स्पष्ट रूप से, असमान रूप से, एक पर्यवेक्षक नहीं है
  • p4पर्यवेक्षक हो सकता है या हो सकता है। हम नहीं जानते, हमें परवाह नहीं है, हमें पता नहीं है (गोपनीयता समस्या?), क्योंकि यह हमारे व्यवसाय में से कोई भी नहीं है।

जब आप उपयोग ==करते हैं तो आप भ्रमित होते हैं nullऔर undefinedजो पूरी तरह से अनुचित है। दो शब्दों का मतलब पूरी तरह से अलग चीजें हैं! यह कहना कि मेरे पास केवल पर्यवेक्षक नहीं है क्योंकि मैंने आपको यह बताने से मना कर दिया कि मेरा पर्यवेक्षक गलत है!

मैं समझता हूँ कि वहाँ प्रोग्रामर जो के बीच इस अंतर के बारे में परवाह नहीं करते हैं nullऔर undefinedया अलग ढंग से इन शब्दों का उपयोग करने के लिए चुनें। और अगर आपकी दुनिया उपयोग नहीं करती है nullऔर undefinedसही ढंग से, या आप इन शर्तों को अपनी व्याख्या देना चाहते हैं, तो यह हो। मुझे नहीं लगता कि यह एक अच्छा विचार है।

अब जिस तरह से मुझे कोई समस्या नहीं है nullऔर undefinedदोनों ही झूठे हैं! यह कहना पूरी तरह से ठीक है

if (p.supervisor) { ... }

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

: और मुझे गैर संक्रामिता पर शुरू नहीं मिलता है "0x16" == 10, 10 == "10"लेकिन नहीं "10" == "0x16"। हां, जावास्क्रिप्ट कमजोर प्रकार की है। हाँ, यह ज़बरदस्ती है। लेकिन जबरदस्ती कभी भी, कभी भी, समानता पर लागू नहीं होनी चाहिए।

वैसे, क्रॉकफोर्ड की मजबूत राय है। लेकिन आप जानते हैं कि क्या? वह यहाँ सही है!

FWIW मैं समझता हूँ कि वहाँ हैं, और मैं व्यक्तिगत रूप से भाग रहा हूँ, ऐसी परिस्थितियाँ जहाँ ==सुविधाजनक है! जैसे कि संख्याओं के लिए स्ट्रिंग इनपुट लेना और, 0. की तुलना करना, हालांकि, यह हैक है। आपके पास दुनिया के एक गलत मॉडल के लिए एक ट्रेडऑफ़ के रूप में सुविधा है।

टीएल; डीआर: मिथ्यात्व एक महान अवधारणा है। इसे समानता तक नहीं बढ़ाया जाना चाहिए।


विभिन्न स्थितियों को दिखाने के लिए धन्यवाद :) हालाँकि, आप गायब हैं p5... एक स्थिति typeof(p5.supervisor) === typeof(undefined)जहाँ पर्यवेक्षक एक अवधारणा के रूप में भी मौजूद नहीं है: D
TheCatWhisperer
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.