Underscore: गैर-सरणी मानों पर सरणी श्रृंखला विधि त्रुटि

यह एक और मुद्दा लाता है, क्या हमें सरणी-पसंद को सरणी में डालना चाहिए?

_('hello').first() // 'h'
_('hello').pop() // ?

ऐसा लगता है कि यह अभी भी एक मुद्दा है - हमने अपने संस्करण को 1.8.3 t0 1.9.0 . से टकराने के बाद इसका सामना किया

संपादित करें: ऐसा लगता है कि यह 1.9.1 में तय किया गया था, यदि हां, तो क्या इस मुद्दे को खुला रहने की आवश्यकता है?

यह व्यवहार अभी भी 1.10.2 में मौजूद है।

मेरे विकल्प में थोड़ा और अधिक ठोस विपरीत, क्योंकि दोनों में एक मूल्य को संशोधित करना शामिल है:

Object.assign(undefined, {a: 1})  // error
_().extend({a: 1})  // undefined

Array.prototype.push.call(undefined, 1)  // error
_().push(1)  // error

मैं कुछ हद तक सहमत हूं कि यह असंगत है।

यह विचार करने योग्य है कि किस तरह की वास्तविक दुनिया की स्थिति में इसका सामना करना पड़ सकता है और ऐसे मामलों में लिपटे वस्तु से क्या उम्मीद की जाए।

एक श्रृंखला के बीच में, लिपटी हुई वस्तु का अनुमान लगाया जा सकता है। उदाहरण के लिए, नीचे दी गई श्रृंखला में, लपेटी गई वस्तु जो push को पास की जाती है, वह या तो Array या undefined होगी। इस कारण से, मैं तर्क दूंगा कि Array रैपर विधियों को एक शून्य जांच लागू करनी चाहिए। यह आसान है।

_.chain(something).map(f).push(x)  // hoping to push x to an array

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

_.chain(something).map(f).join('').push(x)  // hoping to push x to a string??

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

function giveMeAMutableArraylike(something) {
    _.chain(something).push(x)
}

उम्मीद है कि something एक परिवर्तनशील सरणी है जो कई कारणों से पूरी नहीं हो सकती है:

1. giveMeAMutableArraylike $ को किसी भी कारण से null या undefined के साथ बुलाया जा रहा है। यह पहले चेन-इन-द-मिडिल उदाहरण के बराबर है और इसे उसी नल चेक के साथ संबोधित किया जा सकता है।
2. कॉलर giveMeAMutableArraylike को कुछ ऐसा करने की कोशिश कर रहा है जो वह स्पष्ट रूप से नहीं कर सकता, यानी अनुबंध को तोड़ना। यह दूसरे चेन-इन-द-बीच उदाहरण के बराबर है। दोबारा, मुझे लगता है कि इस मामले में एक त्रुटि फेंकना ठीक है।
3. something एक एकल तत्व के साथ एक सरणी के बजाय एक नंगे मूल्य है, अर्थात, $ [v] के बजाय v #$ । कई JavaScript API में यह एक सामान्य स्थिति है। यदि giveMeAMutableArraylike का अनुबंध इसकी अनुमति देता है, तो त्रुटि को फेंकना स्पष्ट रूप से गलत है, भले ही v कुछ भी हो।

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

| वर्तमान व्यवहार | एकल-तत्व सरणी में लपेटें
---|---|---
अनुबंध नंगे एकल तत्व की अनुमति देता है | _प्रोग्रामर को हस्तक्षेप करने की आवश्यकता है_ | अंडरस्कोर स्वचालित रूप से सही काम करता है
अनुबंध नंगे एकल तत्व की अनुमति नहीं देता | अंडरस्कोर स्वचालित रूप से सही काम करता है | _प्रोग्रामर को हस्तक्षेप करने की आवश्यकता है_

साथ ही, आप कैसे तय करते हैं कि कोई मूल्य लपेटा जाना चाहिए या नहीं? कुछ अनुबंध कुछ भी लपेटना चाहते हैं जो Array नहीं है, जबकि अन्य arguments और सादे वस्तुओं को पास करना चाहते हैं। फिर, यह ऐसा कुछ है जो अंडरस्कोर जैसी लाइब्रेरी उपयोगकर्ता की ओर से अनुमान नहीं लगा सकता है।

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

तो मुझे लगता है कि सही समाधान सिर्फ एक शून्य जांच डालना है और इसे उस पर छोड़ देना है। अंडरस्कोर के व्यवहार में यह एकमात्र बदलाव है जो सभी बोधगम्य स्थितियों में बचाव योग्य लगता है और यह _.extend के व्यवहार के अनुरूप भी है। एक नल चेक को अभी भी एक बगफिक्स माना जा सकता है, जबकि इससे अधिक कुछ भी करने से यह जल्दी से एक मनमाना ब्रेकिंग परिवर्तन में बदल जाएगा।

@jashkenas क्या आप इस पर अपना प्रकाश डाल सकते हैं? यदि आप सहमत हैं, तो मैं एक पुल अनुरोध तैयार करूंगा जो शून्य जांच को लागू करता है।

@jgonggrijp - क्या आप उस व्यवहार के साथ एक या दो वाक्यों में विस्तृत कर सकते हैं जिसे आप शून्य जांच के साथ कार्यान्वित करना चाहते हैं?

क्या ऐसा है कि शून्य मान पर कॉल किए जाने पर सरणी विधियां स्पष्ट रूप से अपवाद फेंक देंगी? या कि जब वे एक शून्य मूल्य पर बुलाए जाते हैं तो वे शोर करेंगे?

@jashkenas हाँ। अंडरस्कोर सरणी फ़ंक्शंस की शैली के बाद, मैं जिस व्यवहार को लागू करूंगा वह नो-ऑप है:

https://github.com/jashkenas/underscore/blob/4cf715f593805ba8d7c5685cd06c82b3cd9b55ae/modules/index.js#L495

सिवाय इसके कि length चेक की आवश्यकता नहीं होगी, इसलिए मैं बस सम्मिलित करूंगा

if (obj == null) return chainresult(this, obj);

इन दो पंक्तियों के बीच:

https://github.com/jashkenas/underscore/blob/4cf715f593805ba8d7c5685cd06c82b3cd9b55ae/modules/index.js#L1654 -L1655

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

https://github.com/jashkenas/underscore/blob/4cf715f593805ba8d7c5685cd06c82b3cd9b55ae/modules/index.js#L1665

मुझे ठीक लगता है!