अगर आपके पास Rhino रनटाइम का इस्तेमाल करने वाली कोई मौजूदा स्क्रिप्ट है और आपको V8 सिंटैक्स और सुविधाओं का इस्तेमाल करना है, तो आपको स्क्रिप्ट को V8 पर माइग्रेट करना होगा.
Rhino रनटाइम के ज़रिए लिखी गई ज़्यादातर स्क्रिप्ट में, बदलाव किए बिना V8 रनटाइम का इस्तेमाल किया जा सकता है. किसी स्क्रिप्ट में V8 सिंटैक्स और सुविधाएं जोड़ने के लिए, अक्सर इसके लिए सबसे ज़रूरी होता है कि V8 रनटाइम चालू किया जाए.
हालांकि, कुछ ऐसी समस्याएं होती हैं जो काम नहीं करती हैं और अन्य अंतर भी होते हैं. इनकी वजह से, V8 रनटाइम चालू करने के बाद, स्क्रिप्ट काम करना बंद कर सकती है या अनचाहे तरीके से काम कर सकती है. वर्शन 8 का इस्तेमाल करने के लिए, किसी स्क्रिप्ट को माइग्रेट करते समय, आपको इन समस्याओं के लिए स्क्रिप्ट प्रोजेक्ट में जाकर, समस्याओं को ठीक करना होगा.
V8 माइग्रेशन प्रोसेस
किसी स्क्रिप्ट को V8 पर माइग्रेट करने के लिए, यह तरीका अपनाएं:
- स्क्रिप्ट के लिए, V8 रनटाइम चालू करें.
- नीचे दी गई गड़बड़ी की जानकारी देने वाले लोगों को ध्यान से पढ़ें. अपनी स्क्रिप्ट की जांच करके पता लगाएं कि कोई गड़बड़ी तो नहीं है. अगर एक या उससे ज़्यादा गड़बड़ियां मौजूद हैं, तो समस्या को हटाने या उससे बचने के लिए, अपना स्क्रिप्ट कोड अडजस्ट करें.
- नीचे दिए गए दूसरे अंतर ध्यान से पढ़ें. अपनी स्क्रिप्ट की जांच करें और देखें कि यहां दी गई सूची में शामिल किसी अंतर की वजह से, आपके कोड के काम करने के तरीके पर कोई असर तो नहीं पड़ रहा. कार्रवाई को सही करने के लिए, अपनी स्क्रिप्ट में बदलाव करें.
- पता लगाई गई किसी भी गड़बड़ी या दूसरे अंतर को ठीक करने के बाद, अपने हिसाब से V8 सिंटैक्स और अन्य सुविधाओं का इस्तेमाल करने के लिए, अपना कोड अपडेट करना शुरू किया जा सकता है.
- कोड में बदलाव करने के बाद, अपनी स्क्रिप्ट की अच्छी तरह से जांच करके पक्का करें कि वह उम्मीद के मुताबिक काम कर रही है.
- अगर आपकी स्क्रिप्ट कोई वेब ऐप्लिकेशन है या आपने ऐड-ऑन पब्लिश किया है, तो आपको V8 अडजस्टमेंट की मदद से, स्क्रिप्ट का एक नया वर्शन बनाना होगा. उपयोगकर्ताओं को V8 वर्शन उपलब्ध कराने के लिए, आपको इस वर्शन के साथ स्क्रिप्ट को फिर से पब्लिश करना होगा.
असंगतताएं
माफ़ करें, Rhino पर आधारित Apps Script रनटाइम में, गैर-मानक ECMAscript व्यवहार की अनुमति दी गई है. V8, स्टैंडर्ड का पालन करता है, इसलिए माइग्रेशन के बाद, इस तरह के व्यवहार काम नहीं करते. V8 रनटाइम चालू होने के बाद, इन समस्याओं को ठीक न करने पर गड़बड़ियां हो जाती हैं या स्क्रिप्ट काम नहीं करती.
नीचे दिए गए सेक्शन में, इन सभी व्यवहार के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि वर्शन 8 पर माइग्रेट करने के दौरान, अपने स्क्रिप्ट कोड को ठीक करने के लिए आपको क्या करना होगा.
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 रनटाइम में,
Date.prototype.getYear()
ECMAscript स्टैंडर्ड के मुताबिक,
ज़रूरी वैल्यू के बजाय साल को माइनस 1900 दिखाता है.
अपनी स्क्रिप्ट को 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 स्टैंडर्ड का हिस्सा नहीं थी और इसे ECMAस्क्रिप्ट का पालन करने वाले JavaScript इंजन से हटा दिया गया था. V8 का इस्तेमाल करने वाली स्क्रिप्ट,
इटरेटर के इस निर्माण का इस्तेमाल नहीं कर सकती.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, पसंद के मुताबिक इटरेटर बनाने के लिए, __iterator__ फ़ंक्शन का इस्तेमाल न करें. इसके बजाय,
ECMAScript 6 इटरेटर का इस्तेमाल करें.
कलेक्शन बनाने के लिए इन तरीकों का इस्तेमाल करें:
// 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() का हर इस्तेमाल हटा दें.
अन्य अंतर
ऊपर बताई गई गड़बड़ियों के अलावा, कुछ और अंतर भी हैं. अगर इन्हें ठीक नहीं किया गया, तो स्क्रिप्ट के काम करने के तरीके में गड़बड़ी हो सकती है.
नीचे दिए सेक्शन में बताया गया है कि अनचाहे बदलावों से बचने के लिए स्क्रिप्ट कोड को कैसे अपडेट करें.
स्थान-भाषा के हिसाब से तारीख और समय का फ़ॉर्मैट अडजस्ट करना
Date
तरीका, toLocaleString(),
toLocaleDateString(),
और toLocaleTimeString(), राइनो की तुलना में 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 का इस्तेमाल किया जा सकता है.
यह स्टैक भी स्टैंडर्ड के मुताबिक नहीं है, लेकिन यह Rhino और 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)
|
स्ट्रिंग किए गए Enum ऑब्जेक्ट को हैंडल करने के तरीके में बदलाव करें
मूल Rhino रनटाइम में, किसी enum ऑब्जेक्ट पर JavaScript JSON.stringify() तरीके का इस्तेमाल करने से, सिर्फ़ {} मिलता है.
V8 में, किसी enum ऑब्जेक्ट पर इसी तरीके का इस्तेमाल करने से enum नाम वापस आ जाता है.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय,
enum ऑब्जेक्ट पर
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 से अलग होता है. इसका मतलब है कि कोड में "ग्लोबल 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.
}();
|
वर्शन 8 में, इंप्लिसिट स्पेशल कॉन्टेक्स्ट हटा दिया गया है. स्क्रिप्ट में तय किए गए ग्लोबल वैरिएबल और फ़ंक्शन, ग्लोबल संदर्भ में पहले से मौजूद
Apps Script सेवाओं और Math और Date जैसे ECMAScript बिल्ट-इन के बगल में रखे जाते हैं.
अपनी स्क्रिप्ट को 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 रनटाइम पर चलने वाली स्टैंडअलोन स्क्रिप्ट के लिए, आपको उपयोगकर्ताओं को कम से कम स्क्रिप्ट को देखने का ऐक्सेस देना होगा, ताकि स्क्रिप्ट के ट्रिगर ठीक से काम करें.