mob at embedthis.com
Mon Aug 18 00:24:28 PDT 2008
I should also add that Ejscript (http://www.ejscript.org) successfully
implemented the Program Unit abstraction from ES4 as the basis for a
> Several distinct functions are being mixed by importModule that
> should be separated:
> 1. Addressing the module to be imported in an "external" storage
> hierarchy, whether by URLs on the web or pathnames in a Unix
> filesystem, etc.
We use optional program URLs, but then also allow external resolution
via an search path for modules.
> 2. Whether loading of code from the addressed module is synchronous
> or asynchronous with the call to importModule. Local file access
> probably means importModule is synchronous, but this is wrong for the
> Web browser embedding.
We've assumed synchronous and don't currently have an async mechanism.
> 3. Once having addressed the module and loaded its contents, how the
> module's provided names are required and accessed.
We have done this 2 ways now. First without namespaces where all
module properties were enclosed in a module object that was added to
the scope chain. More recently in keeping with the ES4 proposals, we
used namespaces and module names corresponded to a namespace. Either
way, both approaches have worked well.
> Many times in TC39 we've discussed the module problem, and most agree
> that 1 and 2 do not belong in the Ecma core language specification.
> They belong (at least -- other embeddings matter too) in the HTML5
> Item 3 is important, and there's already some work under way to
> develop an idea based on PLT Scheme, which I'd like to propose for ES-
> Harmony. Dave Herman wrote up a sketch at http://wiki.ecmascript.org/
> doku.php?id=proposals:modules. It has a "Caveat lector".
>>  http://dev.helma.org/wiki/Modules+and+Scopes+in+Helma+NG/
> This page links to http://www.mozilla.org/rhino/
> scopes.html#sharingscopes, which has further sections on sealing and
> dynamic scope (which I remember reading long ago -- see the document
> history). Again, without sealing of the "super-global", there are
> integrity problems.
> Anyway, having a first class module system means not having to worry
> about prototype and scope link cutting and re-welding, etc. This is
> one reason why there must be life beyond ES3.1, which is to say, in
One other thing modules effectively can solve is order of
initialization over multiple program units.
More information about the Es-discuss