Remarks about module import
brendan at mozilla.org
Mon Aug 18 17:59:44 PDT 2008
On Aug 18, 2008, at 5:25 PM, ihab.awad at gmail.com wrote:
> On Mon, Aug 18, 2008 at 5:17 PM, Brendan Eich <brendan at mozilla.org>
>> On Aug 18, 2008, at 5:02 PM, ihab.awad at gmail.com 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
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