स्क्रिप्ट को V8 रनटाइम में माइग्रेट करना

अगर आपके पास Rhino रनटाइम का इस्तेमाल करने वाली कोई मौजूदा स्क्रिप्ट है और आपको V8 सिंटैक्स और सुविधाओं का इस्तेमाल करना है, तो आपको स्क्रिप्ट को V8 पर माइग्रेट करना होगा.

Rhino रनटाइम का इस्तेमाल करके लिखी गई ज़्यादातर स्क्रिप्ट, V8 रनटाइम का इस्तेमाल करके बिना किसी बदलाव के काम कर सकती हैं. आम तौर पर, किसी स्क्रिप्ट में V8 सिंटैक्स और सुविधाएं जोड़ने के लिए, V8 रनटाइम चालू करना ज़रूरी होता है.

हालांकि, काम न करने और अन्य अंतर के कुछ मामले ऐसे हैं जिनकी वजह से V8 रनटाइम चालू करने के बाद, स्क्रिप्ट काम नहीं कर सकती या उसकी परफ़ॉर्मेंस उम्मीद के मुताबिक नहीं हो सकती. V8 का इस्तेमाल करने के लिए स्क्रिप्ट को माइग्रेट करते समय, आपको स्क्रिप्ट प्रोजेक्ट में इन समस्याओं को ढूंढना होगा और उनमें से किसी भी समस्या को ठीक करना होगा.

V8 पर माइग्रेट करने का तरीका

किसी स्क्रिप्ट को V8 पर माइग्रेट करने के लिए, यह तरीका अपनाएं:

  1. स्क्रिप्ट के लिए, V8 रनटाइम चालू करें.
  2. नीचे दी गई इनके साथ काम नहीं करता सूची को ध्यान से देखें. अपनी स्क्रिप्ट की जांच करके देखें कि क्या कोई भी स्क्रिप्ट काम नहीं कर रही है. अगर एक या उससे ज़्यादा स्क्रिप्ट काम नहीं कर रही हैं, तो समस्या को ठीक करने या उससे बचने के लिए, अपनी स्क्रिप्ट के कोड में बदलाव करें.
  3. नीचे दिए गए अन्य अंतर को ध्यान से देखें. अपनी स्क्रिप्ट की जांच करके पता लगाएं कि सूची में दिए गए किसी भी अंतर का आपके कोड के व्यवहार पर असर पड़ता है या नहीं. इस गड़बड़ी को ठीक करने के लिए, अपनी स्क्रिप्ट में बदलाव करें.
  4. काम न करने वाली सुविधाओं या अन्य अंतरों को ठीक करने के बाद, अपने कोड को अपडेट करना शुरू करें. इससे, अपनी पसंद के मुताबिक V8 सिंटैक्स और अन्य सुविधाओं का इस्तेमाल किया जा सकता है.
  5. कोड में बदलाव करने के बाद, अपनी स्क्रिप्ट की पूरी तरह से जांच करें, ताकि यह पक्का किया जा सके कि यह उम्मीद के मुताबिक काम कर रही है.
  6. अगर आपकी स्क्रिप्ट कोई वेब ऐप्लिकेशन या पब्लिश किया गया ऐड-ऑन है, तो आपको 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 रनटाइम में, 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 स्टैंडर्ड का हिस्सा नहीं थी. साथ ही, इसे ECMAScript के मुताबिक काम करने वाले 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 रनटाइम में, किसी iterator को कैसे बनाया जा सकता है. साथ ही, V8 रनटाइम में, किसी iterator को बदलने का तरीका भी बताया गया है:

// 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 untime में, स्टैंडर्ड 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)
      

स्ट्रिंग में बदले गए एनम ऑब्जेक्ट को हैंडल करने का तरीका अडजस्ट करना

ओरिजनल Rhino रनटाइम में, किसी एनम ऑब्जेक्ट पर JavaScript JSON.stringify() तरीके का इस्तेमाल करने पर, सिर्फ़ {} दिखता है.

V8 में, किसी एनम ऑब्जेक्ट पर उसी तरीके का इस्तेमाल करने पर, एनम का नाम दिखता है.

अपनी स्क्रिप्ट को 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 से अलग होता है. इसका मतलब है कि कोड में "ग्लोबल 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 की पहले से मौजूद सेवाएं और 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'));
}

//Project B function setScriptProperties() { PropertiesService.getScriptProperties() .setProperty('project', 'Project-B'); } function getScriptProperties( propertiesService, key) { return propertiesService.getScriptProperties() .getProperty(key); }

// V8 runtime
// Project A
function testPassingNonSharedProperties() {
  PropertiesService.getScriptProperties()
      .setProperty('project', 'Project-A');
  B.setScriptProperties();
  // Prints: Project-A
  Logger.log(B.getScriptProperties(
      PropertiesService, 'project'));
}

// Project B function setProperties() { PropertiesService.getScriptProperties() .setProperty('project', 'Project-B'); } function getScriptProperties( propertiesService, key) { return propertiesService.getScriptProperties() .getProperty(key); }

स्टैंडअलोन स्क्रिप्ट का ऐक्सेस अपडेट करना

V8 रनटाइम पर चलने वाली स्टैंडअलोन स्क्रिप्ट के लिए, आपको उपयोगकर्ताओं को स्क्रिप्ट का कम से कम व्यू ऐक्सेस देना होगा, ताकि स्क्रिप्ट के ट्रिगर सही तरीके से काम कर सकें.