Module isolation

Oliver Hunt oliver at
Mon Jan 18 12:39:34 PST 2010

On Jan 18, 2010, at 12:14 PM, Brendan Eich wrote:

> On Jan 18, 2010, at 11:58 AM, Mark S. Miller wrote:
>> On Mon, Jan 18, 2010 at 10:25 AM, Brendan Eich <brendan at> wrote:
>> On Jan 18, 2010, at 10:20 AM, Mark S. Miller wrote:
>>> I simply don't understand what you mean by the phrase "migrate into a module". What does this mean?
>> Use on the inside of a module. I have code I want to put in a module. It uses Prototype. That's all.
>> How would you express "putting code in a module"? I just don't have a concrete idea what you mean. Could you show a program fragment?
> Copy and paste. I copy prototype- into mybigfatmodule.js, add my special sauce which makes good use of Prototype's extensions to primordials such as Array.prototype, and then purvey it to the world.
>> Why is this hard to understand? Are you assuming modules are small,
>> Or at least, that module boundaries coincide with boundaries between separately written source files, as is the case with module systems I'm familiar with from other languages. For example, Java classes-as-modules.
> Nothing prevents people from inline-expanding Prototype into their code, crashing and carrying whatever they want. The codesearch hits I linked earlier shows instances, including v8's raytrace.js benchmark.
> Would a raytracer with inline-expanded, possibly hand-minimized Prototype make a good module? Maybe, maybe not; I'm not judging, just noticing that people do this sort of thing today on the Web. Modules might reform all bad habits, but probably not -- and developers don't all agree on your definition of "bad".
>> and/or consisting of new code only?
>> Or at least a new revision of old code, in order to repackage the code to do module-based import/export linkage, rather than the current practice of implicit linkage through shared global variables.
> Precedent and developer conversations I've had strongly suggest that some code wants mutable primordials on the inside of a module that can be consumed without the mutations affecting the importer's primordials.
>> Since I do not yet understand what you are trying to say, I may be the wrong person to guess why I'm finding it hard to understand ;). Altogether, my best guess right now is that what you are calling a module is what I would call a sandbox. 
> Could be. Is there a hard difference? It's not obvious.
> Users definitely want isolated frame-like "modules". Some browsers even support such things, with postMessage for safe inter-"module" communication. It's a bit heavyweight, but to get back to the topic of this sub-thread: is the only alternative frozen primordials? I think not.

I agree with Brendan, we've actually been working on "module"-like behaviour with iframes in webkit, basically allowing a detached iframe to remain live as it is passed between documents.  This basically provides a shared code/state repository across multiple pages.  That said this may be a different model than the existing module specifications?

I think something that needs to be cleared up is whether we expect modules to be safely shared with untrusted code (i'm still not sure what people are thinking about this).  The general model in my mind is that each module would be its own global object, with an api object that can be used to vend api to whoever has a reference to the module.  eg. a very ad hoc example, without to much thought given to the API itself, just to describe the model

// Code encapsulated in the module
var bar = 4;
function sqr(x) { return x * x; }
function myFunction(foo) {
   return sqr(foo * bar);

// Vend myFunction to the module api
APIObject.someAPI = myFunction

// Get my module
mymodule = importModule("mymodule.js"); // This should be asynchronous
// A compelling use of an API

Anyhoo, i was just planning on bringing up this model at the f2f next week


> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list