Components.utils.import

Este método fue introducido en Firefox 3 y es usado para compartir código entre diferentes alcances(scopes) de forma sencilla. Por ejemplo, puedes importar XPCOMUtils.jsm para evitar copiar y pegar grandes porciones comunes de código de registración de componentes XPCOM en tus archivos de compomentes.

Components.utils.import("resource://gre/modules/XPCOMUtils.jsm");

Para documentación mira Usando módulos de código JavaScript.

Diferencias con mozIJSSubScriptLoader

Las diferencias con mozIJSSubScriptLoader son:

• El comportamiento cuando se importa/carga el mismo código desde diferentes lugares:
  • el cargador de subscrip evalua el código especificado cada vez que es invocado, con el objeto global del llamador.
  • Components.utils.import evalua el código de cada módulo sólo una vez, en su propio alcance(scope).

  Por ejemplo:

  var scope1 = {}, scope2 = {};
  Components.utils.import("resource://gre/modules/JSON.jsm", scope1);
  Components.utils.import("resource://gre/modules/JSON.jsm", scope2);
  assert(scope2.XPCOMUtils === scope1.XPCOMUtils);
  

  ...retorna true, mientras que:

  var someURL = "resource://gre/modules/JSON.jsm"; 
  var obj1 = {}, obj2 = {}; 
  var loader = Components.classes["@mozilla.org/moz/jssubscript-loader;1"]
                         .getService(Components.interfaces.mozIJSSubScriptLoader); 
  loader.loadSubScript(someURL, obj1); 
  loader.loadSubScript(someURL, obj2);
  assert(obj2 === obj1);
  

  ...retorna false.

  Esto significa que Components.utils.import es más apropiado para compartir código (y datos?) eficientemente entre scripts JS corriendo en diferentes alcances (scopes).

• El cargador de subscript acepta una URL para el código a cargar, mientras que import sólo acepta resource: y file: URIs.

Recursos Adicionales

• bug 238324
• La documentación en xpccomponents.idl
• Los casos de prueba en js/src/xpconnect/tests/unit/