importModule followup

Michael O'Brien mob at
Mon Aug 18 00:24:28 PDT 2008

I should also add that Ejscript ( successfully  
implemented the Program Unit abstraction from ES4 as the basis for a  
modules mechanism.

> 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  
> spec.
> 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
> doku.php?id=proposals:modules. It has a "Caveat lector".
>> [1]
> This page links to
> 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
> Harmony.

One other thing modules effectively can solve is order of  
initialization over multiple program units.

Michael O'Brien

> /be

More information about the Es-discuss mailing list