importModule followup

Brendan Eich brendan at
Mon Aug 18 08:35:18 PDT 2008

On Aug 18, 2008, at 5:58 AM, Maksim Lin wrote:

> 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:
>>> 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)?
> both.

I hate to quibble, but my point (b) was simply that the language  
should support modules in a first-class way. Otherwise, everyone, not  
just Hannes et al. in Helma NG, but at least each JS engine  
maintainer and probably (at first) every engine embedder has to  
reinvent the wheel.

Perhaps we agree. :-/

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

Right, so I see we agree on (b). Again my point in John's blog was  
that without further evolution of the core language, people can only  
reinvent module wheels using baling wire and duct tape (proto/parent  
link cutting/re-welding) in individual embeddings or engines (if they  
upstream the patches).

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

Scripts are synchronously loaded today, but browsers are working on  
async loading techniques, and IE promulgated the defer attribute into  
HTML5. But if importModulel is just a global function, then there's  
no way to avoid blocking mid-script evaluation on it (its call could  
be indirect, obscured). That is not possible in some browsers, and  
not desirable in any event (scripts run to completion, or seem to; no  
preemption, not even by event handlers, unless you fly a dialog that  
allows such things).

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

Yeah; Python is not a bad inspiration but we are looking at PLT- 
Scheme's module system too.

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

For sure -- ES-Harmony.


More information about the Es-discuss mailing list