Hi David, 2013/2/13 David Bruant <bruan...@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 properties. Cheers, Tom
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
