Rhino रनटाइम 31 जनवरी, 2026 को या इसके बाद बंद कर दिया जाएगा. अगर आपके पास Rhino रनटाइम का इस्तेमाल करने वाली कोई मौजूदा स्क्रिप्ट है, तो आपको स्क्रिप्ट को V8 पर माइग्रेट करना होगा.
आम तौर पर, किसी स्क्रिप्ट में V8 सिंटैक्स और सुविधाओं को जोड़ने के लिए, V8 रनटाइम चालू करना ज़रूरी होता है. हालांकि, इनके बीच कुछ अंतर और अन्य अंतर हैं. इनकी वजह से, V8 रनटाइम में स्क्रिप्ट काम नहीं कर सकती या उम्मीद के मुताबिक काम नहीं कर सकती. किसी स्क्रिप्ट को V8 का इस्तेमाल करने के लिए माइग्रेट करते समय, आपको स्क्रिप्ट प्रोजेक्ट में इन समस्याओं को ढूंढना होगा. साथ ही, मिली किसी भी समस्या को ठीक करना होगा.
V8 पर माइग्रेट करने का तरीका
किसी स्क्रिप्ट को V8 पर माइग्रेट करने के लिए, यह तरीका अपनाएं:
- स्क्रिप्ट के लिए, V8 रनटाइम चालू करें. Apps Script प्रोजेक्ट के मेनिफ़ेस्ट का इस्तेमाल करके,
runtimeVersionकी जांच की जा सकती है. - यहां दी गई ज़रूरी शर्तों को ध्यान से पढ़ें. अपनी स्क्रिप्ट की जांच करें, ताकि यह पता चल सके कि कोई समस्या तो नहीं है. अगर एक या उससे ज़्यादा समस्याएं हैं, तो स्क्रिप्ट कोड में बदलाव करके समस्या को ठीक करें या उससे बचें.
- यहां दिए गए अन्य अंतर को ध्यान से देखें. अपनी स्क्रिप्ट की जांच करें. इससे यह पता चलेगा कि सूची में दिए गए अंतरों में से किसी का असर आपके कोड के बिहेवियर पर पड़ता है या नहीं. स्क्रिप्ट में बदलाव करके, इस समस्या को ठीक करें.
- अगर आपको कोई गड़बड़ी मिलती है, तो उसे ठीक करें. इसके बाद, V8 सिंटैक्स और अन्य सुविधाओं का इस्तेमाल करने के लिए, अपने कोड को अपडेट करें.
- कोड में बदलाव करने के बाद, अपनी स्क्रिप्ट को अच्छी तरह से टेस्ट करें. इससे यह पक्का किया जा सकेगा कि स्क्रिप्ट उम्मीद के मुताबिक काम कर रही है या नहीं.
- अगर आपकी स्क्रिप्ट कोई वेब ऐप्लिकेशन है या पब्लिश किया गया ऐड-ऑन है, तो आपको V8 में किए गए बदलावों के साथ स्क्रिप्ट का नया वर्शन बनाना होगा. साथ ही, डिप्लॉयमेंट को नए वर्शन पर पॉइंट करना होगा. V8 वर्शन को उपयोगकर्ताओं के लिए उपलब्ध कराने के लिए, आपको इस वर्शन के साथ स्क्रिप्ट को फिर से पब्लिश करना होगा.
- अगर आपकी स्क्रिप्ट का इस्तेमाल लाइब्रेरी के तौर पर किया जाता है, तो अपनी स्क्रिप्ट का नया वर्शन वाला डिप्लॉयमेंट बनाएं. इस नए वर्शन के बारे में उन सभी स्क्रिप्ट और उपयोगकर्ताओं को बताएं जो आपकी लाइब्रेरी का इस्तेमाल करते हैं. साथ ही, उन्हें V8 की सुविधा वाले वर्शन पर अपडेट करने के लिए निर्देश दें. पुष्टि करें कि आपकी लाइब्रेरी के पुराने वर्शन, जो Rhino पर आधारित हैं, अब इस्तेमाल नहीं किए जा रहे हैं या उन्हें ऐक्सेस नहीं किया जा सकता.
- पुष्टि करें कि आपकी स्क्रिप्ट के कोई भी इंस्टेंस अब भी लेगसी Rhino रनटाइम पर काम नहीं कर रहे हैं. पुष्टि करें कि सभी डप्लॉयमेंट, ऐसे वर्शन से जुड़े हों जो V8 पर हो. पुराने डिप्लॉयमेंट संग्रहित करें. सभी वर्शन देखें और उन वर्शन को मिटाएं जो V8 रनटाइम का इस्तेमाल नहीं कर रहे हैं.
यह सुविधा किन मामलों में काम नहीं करती
Rhino पर आधारित Apps Script रनटाइम में, अफ़सोस की बात है कि कई नॉन-स्टैंडर्ड ECMAScript व्यवहारों की अनुमति दी गई थी. V8, मानकों के मुताबिक है. इसलिए, माइग्रेट करने के बाद इन व्यवहारों का इस्तेमाल नहीं किया जा सकता. इन समस्याओं को ठीक न करने पर, V8 रनटाइम चालू होने के बाद गड़बड़ियां होती हैं या स्क्रिप्ट ठीक से काम नहीं करती.
यहां दिए गए सेक्शन में, इन सभी व्यवहारों के बारे में बताया गया है. साथ ही, V8 पर माइग्रेट करते समय, स्क्रिप्ट कोड को ठीक करने के लिए ज़रूरी चरणों के बारे में बताया गया है.
for each(variable in object) से बचें
for each (variable in object) स्टेटमेंट को JavaScript 1.6 में जोड़ा गया था. हालांकि, इसे for...of के पक्ष में हटा दिया गया था.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, for each (variable in object)
स्टेटमेंट का इस्तेमाल न करें.
इसके बजाय, for (variable in object) का इस्तेमाल करें:
// Rhino runtime var obj = {a: 1, b: 2, c: 3}; // Don't use 'for each' in V8 for each (var value in obj) { Logger.log("value = %s", value); } |
// V8 runtime var obj = {a: 1, b: 2, c: 3}; for (var key in obj) { // OK in V8 var value = obj[key]; Logger.log("value = %s", value); } |
Date.prototype.getYear() से बचें
Rhino के ओरिजनल रनटाइम में, Date.prototype.getYear() फ़ंक्शन, 1900 से 1999 के बीच के सालों के लिए दो अंकों वाला साल दिखाता है. हालांकि, अन्य तारीखों के लिए यह चार अंकों वाला साल दिखाता है. JavaScript 1.2 और इससे पहले के वर्शन में भी ऐसा ही होता था.
V8 रनटाइम में, ECMAScript स्टैंडर्ड के हिसाब से, साल में से 1900 घटाकर वैल्यू दिखाता है.Date.prototype.getYear()
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, हमेशा Date.prototype.getFullYear() का इस्तेमाल करें. इससे तारीख चाहे जो भी हो, साल के चार अंक दिखते हैं.
रिज़र्व किए गए कीवर्ड को नाम के तौर पर इस्तेमाल न करें
ECMAScript में, फ़ंक्शन और वैरिएबल के नामों में कुछ रिज़र्व किए गए कीवर्ड का इस्तेमाल करने की अनुमति नहीं है. Rhino रनटाइम में, इनमें से कई शब्दों का इस्तेमाल किया जा सकता था. इसलिए, अगर आपके कोड में इनका इस्तेमाल किया गया है, तो आपको अपने फ़ंक्शन या वैरिएबल का नाम बदलना होगा.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, वैरिएबल या फ़ंक्शन का नाम रखने के लिए, आरक्षित कीवर्ड का इस्तेमाल न करें.
कीवर्ड के नाम का इस्तेमाल करने से बचने के लिए, किसी भी वैरिएबल या फ़ंक्शन का नाम बदलें. कीवर्ड को नाम के तौर पर इस्तेमाल करने के सामान्य उदाहरण class, import, और export हैं.
const वैरिएबल को फिर से असाइन करने से बचें
Rhino के ओरिजनल रनटाइम में, const का इस्तेमाल करके किसी वैरिएबल का एलान किया जा सकता है. इसका मतलब है कि सिंबल की वैल्यू कभी नहीं बदलती और सिंबल को असाइन किए गए फ़्यूचर असाइनमेंट को अनदेखा कर दिया जाता है.
नए V8 रनटाइम में, const कीवर्ड स्टैंडर्ड के मुताबिक है. साथ ही, इसे const के तौर पर एलान किए गए वैरिएबल को असाइन करने पर, TypeError: Assignment to constant variable रनटाइम गड़बड़ी होती है.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, const वैरिएबल की वैल्यू फिर से असाइन करने की कोशिश न करें:
// Rhino runtime const x = 1; x = 2; // No error console.log(x); // Outputs 1 |
// V8 runtime const x = 1; x = 2; // Throws TypeError console.log(x); // Never executed |
एक्सएमएल लिटरल और एक्सएमएल ऑब्जेक्ट का इस्तेमाल न करें
ECMAScript के इस नॉन-स्टैंडर्ड एक्सटेंशन की मदद से, Apps Script प्रोजेक्ट सीधे तौर पर एक्सएमएल सिंटैक्स का इस्तेमाल कर सकते हैं.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, सीधे एक्सएमएल लिटरल या एक्सएमएल ऑब्जेक्ट का इस्तेमाल न करें.
इसके बजाय, एक्सएमएल पार्स करने के लिए XmlService का इस्तेमाल करें:
// V8 runtime var incompatibleXml1 = <container><item/></container>; // Don't use var incompatibleXml2 = new XML('<container><item/></container>'); // Don't use var xml3 = XmlService.parse('<container><item/></container>'); // OK |
__iterator__ का इस्तेमाल करके, कस्टम इटरेटर फ़ंक्शन न बनाएं
JavaScript 1.7 में एक सुविधा जोड़ी गई है. इसकी मदद से, किसी भी क्लास में कस्टम इटरेटर जोड़ा जा सकता है. इसके लिए, उस क्लास के प्रोटोटाइप में __iterator__ फ़ंक्शन को एलान करना होता है. इसे डेवलपर की सुविधा के लिए, Apps Script के Rhino रनटाइम में भी जोड़ा गया था. हालांकि, यह सुविधा कभी भी ECMA-262 स्टैंडर्ड का हिस्सा नहीं थी. साथ ही, इसे ECMAScript के साथ काम करने वाले JavaScript इंजन से हटा दिया गया था. V8 का इस्तेमाल करने वाली स्क्रिप्ट, इस इटरेटर कंस्ट्रक्शन का इस्तेमाल नहीं कर सकतीं.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, __iterator__ फ़ंक्शन का इस्तेमाल न करें, ताकि कस्टम इटरेटर बनाए जा सकें. इसके बजाय, ECMAScript 6 iterators का इस्तेमाल करें.
नीचे दिए गए ऐरे को बनाने के तरीके पर ध्यान दें:
// Create a sample array var myArray = ['a', 'b', 'c']; // Add a property to the array myArray.foo = 'bar'; // The default behavior for an array is to return keys of all properties, // including 'foo'. Logger.log("Normal for...in loop:"); for (var item in myArray) { Logger.log(item); // Logs 0, 1, 2, foo } // To only log the array values with `for..in`, a custom iterator can be used. |
यहां दिए गए कोड के उदाहरणों में बताया गया है कि Rhino रनटाइम में इटरेटर कैसे बनाया जा सकता है. साथ ही, V8 रनटाइम में रिप्लेसमेंट इटरेटर कैसे बनाया जा सकता है:
// Rhino runtime custom iterator function ArrayIterator(array) { this.array = array; this.currentIndex = 0; } ArrayIterator.prototype.next = function() { if (this.currentIndex >= this.array.length) { throw StopIteration; } return "[" + this.currentIndex + "]=" + this.array[this.currentIndex++]; }; // Direct myArray to use the custom iterator myArray.__iterator__ = function() { return new ArrayIterator(this); } Logger.log("With custom Rhino iterator:"); for (var item in myArray) { // Logs [0]=a, [1]=b, [2]=c Logger.log(item); } |
// V8 runtime (ECMAScript 6) custom iterator myArray[Symbol.iterator] = function() { var currentIndex = 0; var array = this; return { next: function() { if (currentIndex < array.length) { return { value: "[${currentIndex}]=" + array[currentIndex++], done: false}; } else { return {done: true}; } } }; } Logger.log("With V8 custom iterator:"); // Must use for...of since // for...in doesn't expect an iterable. for (var item of myArray) { // Logs [0]=a, [1]=b, [2]=c Logger.log(item); } |
शर्तों के साथ कैच क्लॉज़ का इस्तेमाल न करें
V8 रनटाइम, catch..if के कंडीशनल कैच क्लॉज़ के साथ काम नहीं करता, क्योंकि ये स्टैंडर्ड के मुताबिक नहीं हैं.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, किसी भी कैच कंडीशनल को कैच बॉडी में ले जाएं:
// Rhino runtime try { doSomething(); } catch (e if e instanceof TypeError) { // Don't use // Handle exception } |
// V8 runtime try { doSomething(); } catch (e) { if (e instanceof TypeError) { // Handle exception } } |
Object.prototype.toSource() का इस्तेमाल न करें
JavaScript 1.3 में Object.prototype.toSource() मेथड शामिल था. यह कभी भी किसी ECMAScript स्टैंडर्ड का हिस्सा नहीं था. यह V8 रनटाइम में काम नहीं करता.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, अपने कोड से Object.prototype.toSource() का इस्तेमाल हटाएं.
अन्य अंतर
स्क्रिप्ट के काम न करने की वजह बनने वाली ऊपर बताई गई समस्याओं के अलावा, कुछ और अंतर भी हैं. अगर इन्हें ठीक नहीं किया जाता है, तो हो सकता है कि V8 रनटाइम स्क्रिप्ट उम्मीद के मुताबिक काम न करे.
यहां दिए गए सेक्शन में, स्क्रिप्ट कोड को अपडेट करने का तरीका बताया गया है, ताकि आपको इस तरह की अप्रत्याशित समस्याओं का सामना न करना पड़े.
स्थानीय भाषा के हिसाब से तारीख और समय के फ़ॉर्मैट में बदलाव करना
Date
मेथड toLocaleString(),
toLocaleDateString(), और toLocaleTimeString()
Rhino की तुलना में V8 रनटाइम में अलग तरह से काम करते हैं.
Rhino में, डिफ़ॉल्ट फ़ॉर्मैट लॉन्ग फ़ॉर्मैट होता है. साथ ही, इसमें पास किए गए किसी भी पैरामीटर को अनदेखा किया जाता है.
V8 रनटाइम में, डिफ़ॉल्ट फ़ॉर्मैट शॉर्ट फ़ॉर्मैट होता है. साथ ही, इसमें पास किए गए पैरामीटर को ECMA स्टैंडर्ड के मुताबिक हैंडल किया जाता है. ज़्यादा जानकारी के लिए, toLocaleDateString() दस्तावेज़ देखें.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, स्थानीय भाषा के हिसाब से तारीख और समय के तरीकों के आउटपुट के बारे में, अपने कोड की उम्मीदों को टेस्ट करें और उनमें बदलाव करें:
// Rhino runtime var event = new Date( Date.UTC(2012, 11, 21, 12)); // Outputs "December 21, 2012" in Rhino console.log(event.toLocaleDateString()); // Also outputs "December 21, 2012", // ignoring the parameters passed in. console.log(event.toLocaleDateString( 'de-DE', { year: 'numeric', month: 'long', day: 'numeric' })); |
// V8 runtime var event = new Date( Date.UTC(2012, 11, 21, 12)); // Outputs "12/21/2012" in V8 console.log(event.toLocaleDateString()); // Outputs "21. Dezember 2012" console.log(event.toLocaleDateString( 'de-DE', { year: 'numeric', month: 'long', day: 'numeric' })); |
Error.fileName और Error.lineNumber का इस्तेमाल न करें
V8 रनटाइम में, स्टैंडर्ड JavaScript
Error
ऑब्जेक्ट, कंस्ट्रक्टर पैरामीटर या ऑब्जेक्ट प्रॉपर्टी के तौर पर fileName या lineNumber का इस्तेमाल करने की सुविधा नहीं देता है.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, Error.fileName और Error.lineNumber पर निर्भरता हटाएं.
इसके बजाय, Error.prototype.stack का इस्तेमाल किया जा सकता है.
यह स्टैक भी स्टैंडर्ड नहीं है, लेकिन V8 में काम करता है. दोनों प्लैटफ़ॉर्म से मिले स्टैक ट्रेस का फ़ॉर्मैट थोड़ा अलग होता है:
// Rhino runtime Error.prototype.stack // stack trace format at filename:92 (innerFunction) at filename:97 (outerFunction) |
// V8 runtime Error.prototype.stack // stack trace format Error: error message at innerFunction (filename:92:11) at outerFunction (filename:97:5) |
स्ट्रिंगिफ़ाइड एनम ऑब्जेक्ट को हैंडल करने की सुविधा में बदलाव किया गया
Rhino के ओरिजनल रनटाइम में, किसी enum ऑब्जेक्ट पर JavaScript JSON.stringify() तरीके का इस्तेमाल करने पर सिर्फ़ {} मिलता है.
V8 में, किसी enum ऑब्जेक्ट पर एक ही तरीके का इस्तेमाल करने से enum का नाम मिलता है.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, इनम ऑब्जेक्ट पर JSON.stringify() के आउटपुट के बारे में अपने कोड की उम्मीदों को टेस्ट करें और उनमें बदलाव करें:
// Rhino runtime var enumName = JSON.stringify(Charts.ChartType.BUBBLE); // enumName evaluates to {} |
// V8 runtime var enumName = JSON.stringify(Charts.ChartType.BUBBLE); // enumName evaluates to "BUBBLE" |
तय नहीं किए गए पैरामीटर को हैंडल करने की सुविधा में बदलाव करना
Rhino के ओरिजनल रनटाइम में, किसी तरीके को पैरामीटर के तौर पर undefined पास करने पर, उस तरीके को स्ट्रिंग "undefined" पास की जाती थी.
V8 में, undefined को तरीकों में पास करना, null को पास करने जैसा ही है.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, undefined पैरामीटर के बारे में अपने कोड की उम्मीदों को टेस्ट करें और उनमें बदलाव करें:
// Rhino runtime SpreadsheetApp.getActiveRange() .setValue(undefined); // The active range now has the string // "undefined" as its value. |
// V8 runtime SpreadsheetApp.getActiveRange() .setValue(undefined); // The active range now has no content, as // setValue(null) removes content from // ranges. |
ग्लोबल this को मैनेज करने के तरीके में बदलाव करना
Rhino रनटाइम, इसका इस्तेमाल करने वाली स्क्रिप्ट के लिए एक खास कॉन्टेक्स्ट तय करता है.
स्क्रिप्ट का कोड, इस इंप्लिसिट कॉन्टेक्स्ट में चलता है. यह असल ग्लोबल this से अलग होता है. इसका मतलब है कि कोड में "global this" के रेफ़रंस, असल में खास कॉन्टेक्स्ट का आकलन करते हैं. इसमें सिर्फ़ स्क्रिप्ट में तय किया गया कोड और वैरिएबल शामिल होते हैं. Apps Script की पहले से मौजूद सेवाओं और ECMAScript ऑब्जेक्ट को this के इस इस्तेमाल से बाहर रखा गया है. यह स्थिति, इस JavaScript स्ट्रक्चर से मिलती-जुलती थी:
// Rhino runtime // Apps Script built-in services defined here, in the actual global context. var SpreadsheetApp = { openById: function() { ... } getActive: function() { ... } // etc. }; function() { // Implicit special context; all your code goes here. If the global this // is referenced in your code, it only contains elements from this context. // Any global variables you defined. var x = 42; // Your script functions. function myFunction() { ... } // End of your code. }(); |
V8 में, इंप्लिसिट स्पेशल कॉन्टेक्स्ट को हटा दिया गया है. स्क्रिप्ट में तय किए गए ग्लोबल वैरिएबल और फ़ंक्शन, ग्लोबल कॉन्टेक्स्ट में रखे जाते हैं. ये Apps Script की बिल्ट-इन सेवाओं और ECMAScript के बिल्ट-इन फ़ंक्शन, जैसे कि Math और Date के साथ रखे जाते हैं.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, ग्लोबल कॉन्टेक्स्ट में this के इस्तेमाल के बारे में, अपने कोड की उम्मीदों को टेस्ट करें और उनमें बदलाव करें. ज़्यादातर मामलों में, अंतर सिर्फ़ तब दिखता है, जब आपका कोड ग्लोबल this ऑब्जेक्ट की कुंजियों या प्रॉपर्टी के नामों की जांच करता है:
// Rhino runtime var myGlobal = 5; function myFunction() { // Only logs [myFunction, myGlobal]; console.log(Object.keys(this)); // Only logs [myFunction, myGlobal]; console.log( Object.getOwnPropertyNames(this)); } |
// V8 runtime var myGlobal = 5; function myFunction() { // Logs an array that includes the names // of Apps Script services // (CalendarApp, GmailApp, etc.) in // addition to myFunction and myGlobal. console.log(Object.keys(this)); // Logs an array that includes the same // values as above, and also includes // ECMAScript built-ins like Math, Date, // and Object. console.log( Object.getOwnPropertyNames(this)); } |
लाइब्रेरी में instanceof को मैनेज करने की सुविधा को अडजस्ट करना
किसी ऐसे ऑब्जेक्ट की लाइब्रेरी में instanceof का इस्तेमाल करने पर गलत नेगेटिव मिल सकते हैं जिसे किसी दूसरे प्रोजेक्ट के फ़ंक्शन में पैरामीटर के तौर पर पास किया गया है. V8 रनटाइम में, किसी प्रोजेक्ट और उसकी लाइब्रेरी को अलग-अलग एक्ज़ीक्यूशन कॉन्टेक्स्ट में चलाया जाता है. इसलिए, उनके पास अलग-अलग ग्लोबल और प्रोटोटाइप चेन होती हैं.
ध्यान दें कि ऐसा सिर्फ़ तब होता है, जब आपकी लाइब्रेरी किसी ऐसे ऑब्जेक्ट पर instanceof का इस्तेमाल करती है जिसे आपके प्रोजेक्ट में नहीं बनाया गया है. आपके प्रोजेक्ट में बनाए गए किसी ऑब्जेक्ट पर इसका इस्तेमाल करने से, उम्मीद के मुताबिक काम करना चाहिए. भले ही, वह आपके प्रोजेक्ट की किसी स्क्रिप्ट में हो या किसी दूसरी स्क्रिप्ट में.
अगर V8 पर चल रहा कोई प्रोजेक्ट, आपकी स्क्रिप्ट को लाइब्रेरी के तौर पर इस्तेमाल करता है, तो देखें कि आपकी स्क्रिप्ट, ऐसे पैरामीटर पर instanceof का इस्तेमाल तो नहीं कर रही है जिसे किसी दूसरे प्रोजेक्ट से पास किया जाएगा. instanceof के इस्तेमाल को अडजस्ट करें और इस्तेमाल के उदाहरण के हिसाब से, अन्य विकल्पों का इस्तेमाल करें.
a instanceof b के बजाय, a के कंस्ट्रक्टर का इस्तेमाल किया जा सकता है. ऐसा उन मामलों में किया जा सकता है जहां आपको पूरी प्रोटोटाइप चेन को खोजने की ज़रूरत नहीं है और सिर्फ़ कंस्ट्रक्टर की जांच करनी है.
इस्तेमाल: a.constructor.name == "b"
मान लें कि प्रोजेक्ट A और प्रोजेक्ट B हैं. इनमें प्रोजेक्ट A, प्रोजेक्ट B को लाइब्रेरी के तौर पर इस्तेमाल करता है.
//Rhino runtime //Project A function caller() { var date = new Date(); // Returns true return B.callee(date); } //Project B function callee(date) { // Returns true return(date instanceof Date); } |
//V8 runtime //Project A function caller() { var date = new Date(); // Returns false return B.callee(date); } //Project B function callee(date) { // Incorrectly returns false return(date instanceof Date); // Consider using return (date.constructor.name == // “Date”) instead. // return (date.constructor.name == “Date”) -> Returns // true } |
इसके अलावा, एक ऐसा फ़ंक्शन भी बनाया जा सकता है जो मुख्य प्रोजेक्ट में instanceof की जांच करता है. साथ ही, लाइब्रेरी फ़ंक्शन को कॉल करते समय, अन्य पैरामीटर के साथ-साथ इस फ़ंक्शन को भी पास करता है. इसके बाद, पास किए गए फ़ंक्शन का इस्तेमाल लाइब्रेरी में instanceof की जांच करने के लिए किया जा सकता है.
//V8 runtime //Project A function caller() { var date = new Date(); // Returns True return B.callee(date, date => date instanceof Date); } //Project B function callee(date, checkInstanceOf) { // Returns True return checkInstanceOf(date); } |
लाइब्रेरी में शेयर नहीं किए गए संसाधनों को पास करने की सुविधा को अडजस्ट करना
V8 रनटाइम में, मुख्य स्क्रिप्ट से लाइब्रेरी में शेयर नहीं किया गया संसाधन पास करने का तरीका अलग होता है.
Rhino रनटाइम में, शेयर नहीं किए गए संसाधन को पास करने पर, यह काम नहीं करेगा. इसके बजाय, लाइब्रेरी अपने संसाधन का इस्तेमाल करती है.
V8 रनटाइम में, लाइब्रेरी को शेयर नहीं किया गया संसाधन पास करने पर काम करता है. लाइब्रेरी, पास किए गए ऐसे नॉन-शेयर्ड रिसॉर्स का इस्तेमाल करती है.
शेयर नहीं किए गए संसाधनों को फ़ंक्शन पैरामीटर के तौर पर पास न करें. जिन स्क्रिप्ट में शेयर नहीं किए गए संसाधनों का इस्तेमाल किया जाता है उनमें हमेशा इन संसाधनों के बारे में जानकारी दें.
मान लें कि प्रोजेक्ट A और प्रोजेक्ट B हैं. इनमें प्रोजेक्ट A, प्रोजेक्ट B को लाइब्रेरी के तौर पर इस्तेमाल करता है. इस उदाहरण में, PropertiesService एक ऐसा संसाधन है जिसे शेयर नहीं किया जाता.
// Rhino runtime // Project A function testPassingNonSharedProperties() { PropertiesService.getScriptProperties() .setProperty('project', 'Project-A'); B.setScriptProperties(); // Prints: Project-B Logger.log(B.getScriptProperties( PropertiesService, 'project')); } |
// V8 runtime // Project A function testPassingNonSharedProperties() { PropertiesService.getScriptProperties() .setProperty('project', 'Project-A'); B.setScriptProperties(); // Prints: Project-A Logger.log(B.getScriptProperties( PropertiesService, 'project')); } |
स्टैंडअलोन स्क्रिप्ट को ऐक्सेस करने की अनुमति अपडेट करना
V8 रनटाइम पर चलने वाली स्टैंडअलोन स्क्रिप्ट के लिए, आपको उपयोगकर्ताओं को स्क्रिप्ट का कम से कम व्यू ऐक्सेस देना होगा, ताकि स्क्रिप्ट के ट्रिगर ठीक से काम कर सकें.