Remarks about module import

not

Hi folks,

The module system proposals, especially the one here --

  http://wiki.ecmascript.org/doku.php?id=proposals:modules

are pretty cool; I took the liberty of not following Dave Herman's
advice to not pay it much attention. ;) Here are some comments coming
from where I sit on the Caja team, and thus with a strong emphasis on
security.

== Module naming ==

The declared name of a module, e.g. "A" in --

  module A { ... }

is either meaningful or meaningless. ;) If it is meaningful, it means
that the module itself gets to specify where it lives in the
namespace(s) owned by the importing entity. That is an improper (read:
insecure) inversion of responsibility; what a module, upon being
imported, is called by its importer is properly none of its business.
And if the module name is meaningless, then we don't need it.

By that argument, I would like to propose that a module and a
"compilation unit" (or ES3 <Program>) be merged into one concept. This
has the useful side effect that the loading of a top-level program
(whatever that is, and wherever it comes from) can be re-explained
simply in terms of the loading of a module.

== Exchange of objects ==

I strongly suggest that the importer supply an explicit map giving
symbol bindings for the loaded module, , i.e., I don't think the
imported module should automatically inherit the lexical scope at the
import point. The module's code is typically not under the direct
control of the importer, so allowing it to schlep all its importer's
lexical variables is giving it too much dangerous power.

The module itself can gain access to the symbols supplied by the
caller via some sort of a "require" syntax; that said, our position in
the Caja project has been to simply recognize that certain variables
in a [Caja] module are free, and expect the importer to provide
bindings (and bind them to "undefined" if the importer fails to
provide bindings). I think this is simpler than the "require" syntax
and meshes nicely with the existing way that symbols (like "document"
and "window") are provided to top-level code in ES embeddings.

Finally, the importing code should be in full control of what names
are inserted into its own scope; this again is important for security.
In fact, this point is important enough that I would leave out any
sort of "import *" functionality, relegating to IDEs the task of
helping manage explicit import lists.

== An example ==

Consider a module file located at the URL --

  http://foo.com/someModule.js

containing the text --

  var isOn = false;
  provide
      toggle: function() {
        document.setBackgroundColor(isOn ?
            background : '#ffffff');
        isOn = !isOn;
      },
      set: function() {
        document.setBackgroundColor(background);
        isOn = true;
      };

This code has two free variables, "document" and "background", and
returns the symbols "toggle" and "set" to the importer. The module
also has state, implying that it can be instantiated multiple times.

An importer could use this as follows --

  var doc = ...;
  var bg = ...;

  import
      of fetchModule('http://foo.com/someModule.js'),
      with document: doc, background: bg
      using t: toggle, s: set;

  // "t" and "s" are now in scope

This would desugar to something like --

  var doc = ...;
  var bg = ...;

  var temp___ = importModule(
      fetchModule('http://foo.com/someModule.js'),
      { document: doc, background: bg });
  var t = temp___.toggle;
  var s = temp___.set;

Note that I have used "fetchModule" as a shortcut to say that I am
punting on the semantics of how a module is located and the
concurrency semantics whereby its text is retrieved (per Brendan's
points made earlier).

To exchange symbols without renaming them, we could abbreviate to --

  var document = ...;
  var background = ...;

  import
      of fetchModule('http://foo.com/someModule.js'),
      with document, background
      using toggle, set;

  // "toggle" and "set" are now in scope

== Reference to Caja modules ==

We have a preliminary writeup of how we would like to think about
module loading in Caja here --

  http://google-caja.googlecode.com/svn/trunk/doc/html/cajaModuleSystem/index.html

Hope this helps. Cheers,

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA

Remarks about module import

I strongly suggest that the importer supply an explicit map giving

symbol bindings for the loaded module, i.e., I don't think the

imported module should automatically inherit the lexical scope at

the import point. The module's code is typically not under the

direct control of the importer, so allowing it to schlep all its

importer's lexical variables is giving it too much dangerous power.