Only two sensible "null realm" options

Mark S. Miller erights at
Thu Dec 20 10:58:55 PST 2012

Chat below forwarded with Tom's permission. Conclusion is that, if we
go the getter/setter null-realm route, we should either do the minimal
null realm, with only getter/setter objects with null prototype (which
isn't observably a realm at all), or we should use SES as the null
realm. We both think it's premature to try to standardize SES, so
let's do the first.

me: Should the null realm in the recent thread be a SES realm?
Tom: apart from freezing Function.prototype etc., what else does an
SES realm provide?
        probably a modified Function constructor, for starters
me: yes. and a modified eval. Full list at
Tom: is the modified eval/Function constructor necessary to ensure an
immutable realm?
me: depends what u mean by immutable.
Tom: right :)
        David's concern is a communications channel
        so I guess it means only externally readable mutable state
        if all objects in that null realm are frozen from the start, I
don't think that is possible
        even if eval'ed code created new mutable objects, it wouldn't
have a place to store them
me: what is the null realm's global object?
      can evaled code create new global variables?
Tom: good question. I have no idea. Might be simply an empty frozen object?
         right, because declared globals would end up as properties on
the global. If the global is frozen,
         this should probably fail as well?
me: then this would be very close to SES.
       eval and Function are modified mostly to have exactly that
effect, but without needing to change
       the real global.
       Please have a look at that page.
Tom: I see that Date.prototype can also pose issues with mutable state
         those would also need to be fixed in this scenario
         so you're right
         well, it's either that, or the getter/setters simply have a
null prototype and are marked frozen
me: I hope/think we've already agreed to fix Date and WeakMap in ES6,
so that's hopefully not an issue.
Tom: letting the getters/setters have a null prototype seems to be a
simple and effective option
me: However, because we didn't fix
       if the null realm does have prototypes, they should be
tamperProof rather than simply frozen.
       so I think if we go beyond null prototypes, we should go all
the way to SES.
Tom: by tamperProof you mean the trick whereby you change all data
props into accessors?
me: on alleged prototype objects, yes.
Tom: I agree
        although probably making the prototype be null is more than sufficient.
me: agreed. that's probably best for this stage, since I don't want to
try to standardize SES at this time.
Tom: yes, that's probably out of the question before ES6


More information about the es-discuss mailing list