On Aug 18, 2008, at 5:25 PM, [EMAIL PROTECTED] wrote: > On Mon, Aug 18, 2008 at 5:17 PM, Brendan Eich <[EMAIL PROTECTED]> > wrote: >> On Aug 18, 2008, at 5:02 PM, [EMAIL PROTECTED] 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? /be _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
