2010-10-22 18 views
5

तो ECMAScript 5 ECMAScript 3.यह सुनिश्चित करने के लिए कि ES3 प्रोग्राम ES5 इंजन में कैसे चलेंगे?


उदाहरण के साथ कुछ असंगतियां का परिचय:

Manyarticles करते हुए कहा कि this === null || this === undefined ES5 सख्त मोड में संभव है लिखा गया है:

"use strict"; 
(function() { 
    alert(this); // null 
}).call(null); 

लेकिन, the standard क्या है वास्तव में पता चलता है कि ES5 इंजन भी गैर सख्त मोड में इस अनुमति देते हैं:

15.3.4.3 ... thisArg मूल्य this मूल्य के रूप में संशोधन के बिना पारित कर दिया है। इस संस्करण 3, जहां एक undefined या null thisArg वैश्विक वस्तु साथ बदल दिया है और ToObject अन्य सभी मूल्यों को लागू किया जाता है और उस परिणाम this मूल्य के रूप में पारित हो जाता है से एक परिवर्तन है।

वर्तमान में, आईई 9 एकमात्र ब्राउज़र है जो वास्तव में इस तरह ईएस 5 लागू करता है, और यह पता चला है कि यह break current scripts हो सकता है। महान।


ES5 spec में एनिक्स ई की अन्य असंगतताओं की सूची है।

तो यकीन है कि हमारे अच्छी तरह से करने की कोशिश की ES3 लिपियों दोषरहित चलते रहेंगे बनाने के लिए सबसे अच्छा तरीका क्या है? किसी प्रकार का स्वचालित परीक्षण-सूट? क्या हमें इसे मैन्युअल रूप से जांचना होगा?

उत्तर

4

स्वचालित टेस्ट स्वीट निश्चित रूप से एक अच्छा विचार है।

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

मैं और अधिक लोकप्रिय कार्यान्वयन में से कुछ के समर्थन के स्तर लिस्टिंग एक ES5 compatibility table है,। यह पूर्ण नहीं है, लेकिन यह समग्र दिशा दिखाता है - कि नवीनतम आईई, वेबकिट, क्रोम और फ़ायरफ़ॉक्स में काफी अच्छा ईएस 5 समर्थन है। एक पूर्ण अनुरूपता परीक्षण के लिए, आप हमेशा आधिकारिक ES5 टेस्ट स्वीट (जो मैं सुविधा right here के लिए ऑनलाइन है) चला सकते हैं।

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

Annex E परामर्श जाना एक और तरीका है। ध्यान दें कि भले ही सूची काफी बड़ी लगती है, लेकिन ऐसा लगता है कि यह उतना बुरा नहीं है जितना लगता है। ईएस 5 के लक्ष्यों में से एक ईएस 3 से अधिक या कम दर्द रहित संक्रमण करना था, के दायरे में अधिक कट्टरपंथी परिवर्तनों को स्थानांतरित करना सख्त मोड में ऑप्ट-इन करना था।

उस सूची से कई संगतता परिवर्तनों पर ध्यान नहीं दिया जा सकता है। उदाहरण के लिए, 15.1.1 में बदलें, जहां वैश्विक undefined, NaN और Infinity अब केवल पढ़ने के लिए हैं।यह मानते हुए कि सायन अनुप्रयोग इन वैश्विक गुणों को पुन: असाइन नहीं करते हैं - को गलती से - यह परिवर्तन "ऐप-ब्रेकर" के बजाय सुखद "त्रुटि-पकड़ने वाला" है।

एक और liekly निर्दोष परिवर्तन 15.10.2.12, जहां खाली स्थान के चरित्र वर्ग (\s) अब भी मेल खाता है < बीओएम> (U+FEFF) चरित्र में है। वर्तमान कार्यान्वयन में भी all the deviations को ध्यान में रखते हुए (यहां तक ​​कि ES3 के संबंध में), इस परिवर्तन को अधिकांश अनुप्रयोगों में अनजान होने की संभावना है।

हालांकि, भी में खतरनाक परिवर्तन parseInt में हैं और यह अब 0 से शुरुआती तारों के साथ स्ट्रिंग्स का व्यवहार कैसे करता है। parseInt('010') अब 8 का उत्पादन नहीं करना चाहिए (हालांकि कुछ कार्यान्वयन deliberately violate that behavior पर चुना गया है)। और फिर भी, दूसरे "रेडिक्स" तर्क के बिना parseInt पर भरोसा करना कभी अच्छा अभ्यास नहीं था। तो यदि आपका एप्लिकेशन हमेशा रेडिक्स निर्दिष्ट करता है, तो चिंता करने की कोई बात नहीं है।

तो एनेक्स ई से परामर्श लें, अपनी स्क्रिप्ट का परीक्षण नए कार्यान्वयन (अधिमानतः, एकाधिक वाले) में करें, और सर्वोत्तम प्रथाओं का पालन करें। संगतता सुनिश्चित करने के लिए यह एक अच्छा तरीका है।

+0

आपका परीक्षण सूट वास्तव में अच्छी चीजें है। हालांकि, मुझे डर है कि यह मेरी विशेष स्थिति में मदद नहीं करेगा। असल में, मेरी कंपनी को यह सुनिश्चित करने की ज़रूरत है कि हमारी विरासत स्क्रिप्ट हमारे ग्राहकों के प्रतिष्ठानों में कोई समस्या नहीं पैदा करेगी। हम यहां सैकड़ों और सैकड़ों स्क्रिप्ट के बारे में बात कर रहे हैं, और मैन्युअल रूप से प्रत्येक कार्यक्षमता की जांच करने से बहुत दर्द होता है। ("यूनिट परीक्षण? वह क्या है?") वर्तमान में, मुझे डर है कि हम बस बग रिपोर्ट के लिए इंतजार कर रहे हैं। – user123444555621

+0

JSLint के माध्यम से स्क्रिप्ट चलाने के बारे में कैसे? एक करके, थोड़ा सा छोटा।जेएसलिंट में सभी कंपैट-संवेदनशील परिवर्तन शामिल नहीं हो सकते हैं, लेकिन यह निश्चित रूप से आपको बंद कर देगा। यह parseInt w/o radix, और संपत्ति के नामों के बारे में कीवर्ड के रूप में चेतावनी देगा (उदा। '({If: 1}) '), और अन्य। – kangax

+0

दुर्भाग्यवश, जेएसलिंट हजारों त्रुटियों की रिपोर्ट करेगा, और कभी-कभी जारी रखने से इंकार कर देगा (उदाहरण के लिए जब 'शून्य' मारते हैं) भले ही स्क्रिप्ट ईएस 3 में ठीक हो। वास्तव में, मैंने अतीत में कुछ जेएसलिंट मोड बनाए हैं, और मैं कुछ ईएस 5 सामान जोड़ने के बारे में भी सोच रहा हूं। हालांकि, कुछ असंगतताओं (7.8.5/1, 10.4.2, 10.6/2, 15.3.4.3, 15.3.4.4, 15.10.2.12) पार्स-टाइम पर खोजने में बहुत मुश्किल हैं। – user123444555621

6

रिकॉर्ड के लिए, ईएस 5 15.3.4.3 की प्रश्नकर्ता की व्याख्या गलत है। ईएस 5 में एक गैर-सख्त कार्य करने के लिए कोई भी कॉल ईएस 3 जैसा ही होना चाहिए। वैश्विक वस्तु अभी भी किसी भी गैर-सख्त कार्य में पारित की जाती है जिसे इस मान के रूप में शून्य या अपरिभाषित कहा जाता है।

विश्लेषण के गायब टुकड़ा 10.4.3 "में प्रवेश कर फंक्शन कोड" है:

निम्न चरणों को जब नियंत्रण में प्रवेश करती है एक समारोह वस्तु में निहित एफ समारोह कोड के लिए निष्पादन संदर्भ प्रदर्शन कर रहे हैं, एक फोन करने वाले thisArg प्रदान की है, और एक फोन करने वाले argumentsList प्रदान की:

  1. तो च एकीकरण कोड सख्त कोड है, इस बाइंडिंग को पर सेट करें यह ARR
  2. वरना अगर thisArgअशक्त या अपरिभाषित है, वैश्विक वस्तु को ThisBinding निर्धारित किया है।
  3. ...

ES3 निर्दिष्ट किया है कि फोन करने वाले एक अशक्त के लिए वैश्विक वस्तु प्रतिस्थापन के लिए जिम्मेदार था या यह मान अपरिभाषित। ES5 निर्दिष्ट करता है कि कैली में उस जिम्मेदारी है (यदि यह सख्त मोड फ़ंक्शन नहीं है)। गैर-सख्त कोड के लिए यह एक अवलोकन अंतर नहीं है। विनिर्देश परिवर्तन केवल तभी फर्क पड़ता है जब कैली एक सख्त कार्य होता है।

+0

टाइपो: "मान के रूप में अपरिभाषित" –

+0

@ एक्सेलरोशमेयर-ईएस 5 को इस तरह से काम करना है क्योंकि कॉलर को यह नहीं पता है कि कैली सख्त मोड में है या नहीं। तो कॉल से * thisArg * गुजरना और कैली को सॉर्ट करना इसे समझ में आता है। :-) – RobG