A case for removing the seal/freeze/isSealed/isFrozen traps
Tom Van Cutsem
tomvc.be at gmail.com
Wed Feb 13 11:36:53 PST 2013
2013/2/13 David Bruant <bruant.d at gmail.com>
> Le 12/02/2013 14:29, Brendan Eich a écrit :
>> Loss of identity, extra allocations, and forwarding overhead remain
> I'm doubtful loss of identity matters often enough to be a valid argument
> here. I'd be interested in being proved wrong, though.
I do think identity is an issue in practice, especially without a membrane
in-place to preserve object identity across the membrane. Also:
> It's true you want either a membrane or an already-frozen object in such
>> a setting.
> Not a membrane, just a proxy that protects its target. Objects linked from
> the proxy likely came from somewhere else. They're in charge of deciding of
> their own "integrity policy".
"Freezing" an object by handing out a read-only view is fragile without a
full membrane: what if a method of the wrapped object returns |this|, or
passes its |this| argument to some client-provided callback? It's all too
easy for a direct reference to the target to escape, thus bypassing the
read-only view. This is not the case with frozen objects.
I went a bit too far suggesting frozen objects could de-facto disappear
> with proxies.
> I'm still unclear on the need for specific seal/freeze/isSealed/isFrozen
I think Allen and I reached consensus that we might do without those traps.
In addition, Allen was considering an alternative design where the "state"
of an object (i.e. "extensible", "non-extensible", "sealed" or "frozen") is
represented explicitly as an internal property, so that Object.isFrozen and
Object.isSealed must not "derive" the state of an object from its
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss