Module isolation

David-Sarah Hopwood david-sarah at
Mon Jan 11 10:53:31 PST 2010

Brendan Eich wrote:
> On Jan 10, 2010, at 9:30 PM, David-Sarah Hopwood wrote:
>> Brendan Eich wrote:
>>> On Jan 10, 2010, at 1:14 AM, Kevin Curtis wrote:
>>>> From SecureEcmaScript proposal:
>>>> 6. The top level binding of this in an evaled Program is not the
>>>> global object, but rather a frozen root object containing just the
>>>> globals defined in the ES5 spec.
>>> For many current applications, the frozen |this| object is not necessary
>>> or desirable in global code. The essential characteristic of modules,
>>> isolation for each module's "inside" from unimported effects of other
>>> modules, does not necessarily mean no mutation of primordial objects.
>> On the contrary, it does necessarily mean that. If you can mutate
>> primordial objects, then there is no isolation of any module. There
>> may be a reduction in the possibilities for accidental interference
>> between modules, but that should be distinguished from isolation.
> Who said primordial objects are shared between modules?

Having separate copies of primordial objects for each module is not
sufficient to ensure isolation. If one module has access to some object
obj of another, it can also get access to that object's prototype chain
using Object.getPrototypeOf(obj), or obj.constructor.prototype.

OTOH, I was incorrect in saying that mutable primordials *necessarily*
preclude isolation. It would be possible to virtualize mutations to a
module's primordials so that they are only visible to that module, in
the same way that Valija does. I don't favour that approach because it
is very much more complicated.

David-Sarah Hopwood  ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the es-discuss mailing list