importModule followup

Maksim Lin maksim.lin at
Mon Aug 18 05:58:27 PDT 2008

On Mon, Aug 18, 2008 at 2:42 PM, Brendan Eich <brendan at> wrote:
> 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)?


> 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

point very well taken! you're very right, properties in the global
scope that are objects themselves are up for modification and thats
exactly the reason for sealed objects being discussed (as you say) on
the rhino docs page. But if this was a std language or embedding
implementaton feaure then no one would need to reinvent it.

> I'd like to hear more about Helma NG does it.

Hopefully Hannes can chime in on this, as I've not had a proper look
at how its implemented, rather just been using it to write some small
js modules using the new interface.
>From that perspective it works well - perhaps not well enough to stop
the complete global scope modification, but certainly enough for
module writers to not step on each others toes and let module user
easily seperte out the modules into clear 'namespaces'.

> 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.

well I guess this is something hat should be left up to the embedding,
so yet anther reason perhaps for this to be specified the same way
<script> is - outside of ES spec.

> 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.

yes completely aagree. I do tend to ahve a servr side slant to my thinking.
But then again coldn't it be the same a for <script> elements?

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

Well Helma NG has a sensible default and also lets you specify an
optional name prefix.

> 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.

yep completely agree as I said above.

> 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
> It has a "Caveat
> lector".

thanks for the ref, I'l make sure to read through it.

> 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

I would assume that anykind of modules proposal would be post 3.1 ?


More information about the Es-discuss mailing list