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

Hi David,

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
>> problems.
> 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
> traps

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...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130213/f8d4a19e/attachment-0001.html>

More information about the es-discuss mailing list