Remarks about module import

Brendan Eich brendan at
Mon Aug 18 17:59:44 PDT 2008

On Aug 18, 2008, at 5:25 PM, ihab.awad at wrote:

> On Mon, Aug 18, 2008 at 5:17 PM, Brendan Eich <brendan at>  
> wrote:
>> On Aug 18, 2008, at 5:02 PM, ihab.awad at wrote:
>>> That said, we in Caja land have worried about
>>> whether *some* default global properties should be made available --
>> Why couldn't they be imported from a standard module? Must  
>> everything be
>> passed down? Maybe in Caja, but I don't see that as a requirement on
>> successor ES standards.
> Even in Caja, it's possible for one module to import another. What
> needs to be passed down is *authority*, not the ability to execute
> code.

I was asking, I'm happy with an answer. But what's the requirement,  
exactly? Can you give an example?

> But ok, yes, if people like the idea of using an "importModule"
> construct to get the "Function" and "Number" objects, say, then sure,
> that's a great solution.

I didn't ask what people like. That's for later ;-).

I thought you suggested that a few built-ins (Function, Number, not  
Date) were safe to populate in a global scope, "above" a module's  
apparent top lexical scope. A safe (immutable, I hope) top-level. Do  
I have that right?

> What it means essentially is that the "importModule" construct, plus
> some "fetchModule" service that knows where to find the primordial
> objects, together constitute the material provided to a module by
> default. If this can be made to work cleanly while allowing
> user-supplied "fetchModule" implementations that get module code from
> (say) a database or whatever, then that's peachy.

Could be. Dave's sketch was not ready for prime time in his own  
words, but one of the first objections to it (which may be perfectly  
fair, I don't know) was about modules giving themselves names, used  
elsewhere in requires statements.

Your post asserted that responsibility for naming a module belongs to  
the importer (requirer? ugh). That could be the whole truth, or half  
of it. Provider and requirer might both want to use distinct names.

If requires consulted a different namespace from the property map of  
any object (especially of the global object), would that be insecure?

I'm familiar with objcap research, but I still get a strange feeling  
around jargon from it (sort of like I'm being inducted into a new  
religion). *Authority*, *responsibility*, etc. are well-defined in  
the literature, maybe (one hopes), but their application here, their  
use as short-hand arguments, may be less clear and convincing to the  
outsiders than you would hope.

(And however convincing I find the definitions and arguments in the  
literature, when I hear the summary judgments, I often feel that I've  
been *told* :-/. I'll cope...)

Could you expand on why it's inevitably insecure to have a module  
system with self-named modules accessible in some namespace built up  
by special forms such as Dave's module syntax?


More information about the Es-discuss mailing list