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
code.google.com/p/google-caja/wiki/SES
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
strawman:fixing_override_mistake
,
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
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
http://code.google.com/p/google-caja/wiki/SES
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
http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake
,
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
--
Cheers,
--MarkM
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 code.google.com/p/google-caja/wiki/SES 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 strawman:fixing_override_mistake , 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
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 http://code.google.com/p/google-caja/wiki/SES 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 http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake , 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 -- Cheers, --MarkM