importModule followup

Michael O'Brien 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  
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 http://wiki.ecmascript.org/
> doku.php?id=proposals:modules. It has a "Caveat lector".
>
>
>> [1] 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
> 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