As promised, more detail on Solution 2.
Reviewing the problematic case:
// zero.js:
module jQuery = load 'jquery.js';
module Drawing = load 'footgun.js';
module One = load 'one.js';
// one.js:
import jQuery.ajax;
module Two = load 'two.js';
// two.js:
import jQuery.ajax;
import Drawing.draw;
draw(); // intended to draw a picture
There are dual formulations of the problem:
(a) The author of "one.js" is not given the opportunity to intermediate the
name propagation -- they can neither control the names introduced by
"zero.js", nor hide them from the view of "two.js"; or
(b) The names used in "import" statements are short, local nicknames,
admitting of diverse interpretations as to their semantics.
This specific solution to the problem attempts to show the consequences of
approach (b). In other words, if we got everyone to "import" via names that
have a low likelihood of collision, then modules "zero.js", "one.js" and
"two.js" can, assuming good intentions (our scheme is not intended to guard
against malice), cooperate to populate that namespace.
We can construct long-winded names that are unlikely to collide, perhaps
using DNS. Therefore, a module can:
import ... "com.drawings.art" ...;
or, to use XML namespace-like URIs-as-names:
import ... "http://art.drawings.com/module"; ...;
The mapping from the uttered name to an actual code resource can occur in
any of a number of places. Perhaps each loader has a single mapping. Perhaps
each module can override the mappings for each module that it "load"s. The
point is that these names are known to be distinct from:
import ... "com.guns.footshooting" ...;
The important thing is that we are now importing *names*, not just capturing
program identifiers, and the semantics are those of a map lookup somewhere.
Ihab
--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
