brendan at mozilla.org
Sun Aug 17 21:42:00 PDT 2008
On Aug 17, 2008, at 8:59 PM, Maksim Lin wrote:
> In a comment on John Resigs blog about ES-Harmony, Hannes Wallnoefer
> suggested that a simple module system he has implemented for helma-ng
>  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
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
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".
>  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
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
More information about the Es-discuss