importModule followup

Brendan Eich brendan at mozilla.org
Sun Aug 17 21:42:00 PDT 2008


On Aug 17, 2008, at 8:59 PM, Maksim Lin wrote:

> Hi,
>
> In a comment on John Resigs blog about ES-Harmony, Hannes Wallnoefer
> suggested that a simple module system he has implemented for helma-ng
> [1] could be used for a future ES versions implementation.
>
> I think Brendan may have misunderstood the proposal as in a later
> comment he said that :
> "...Hannes points out how to solve it in-language, but that wheel is
> (a) a leaky abstraction, which could be abused; (b) something no one
> should have to re-invent."
>
> which I dont think is right

Which point, (a) or (b)?


> since the way I understand Hannes
> importModule() to work is that the code that is "imported" from the
> corresponding js file is given a new object as its parent scope
> (rather then the global one) and then that objects prototype is set to
> the global scope. Tis then prevents the imported code from modifying
> the "real" gloabl scope while still giving it read-access to it.
> Hopefully I've explained it correctly, so apologies to Hannes if I  
> haven't.

This does not work, since it is possible to mutate the properties of  
mutable objects named by properties on the prototype chain, not  
merely shadow prototype properties by assigning direct properties of  
the same name. But I'd like to hear more about Helma NG does it.


> But I can't see how does that work as "in-language". To me it seems
> that this requires the js implementation to do the above (messing with
> the parent scope of the imported code) as it can't be done by the
> application programmer in js unless you use a bunch of proprietary moz
> API's like the mock example on the helma-ng page:

Right. Magic not expressible in the language must be used, or there  
will be integrity problems, or to put it another way, abstraction leaks.


> So instead why not have a new standard function importModule() that
> does the above as part of the language spec?

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.

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.

3. Once having addressed the module and loaded its contents, how the  
module's provided names are required and accessed.

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.

/be





More information about the Es-discuss mailing list