A case for removing the seal/freeze/isSealed/isFrozen traps

Andreas Rossberg rossberg at google.com
Thu Feb 14 09:11:29 PST 2013

On 13 February 2013 13:39, David Bruant <bruant.d at gmail.com> wrote:
> Warning: In this post, I'll be diverging a bit from the main topic.
> 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 understand the point about extra allocation. I'll talk about that below.
> The forwarding overhead can be made inexistent in the very case I've exposed
> because in the handler, the traps you care about are absent from the
> handler, so engines are free to optimize the [[Get]]&friends as operations
> applied directly to the target.

You're being vastly over-optimistic about the performance and the
amount of optimisation that can realistically be expected for proxies.
Proxies are inherently unstructured, higher-order, and effectful,
which defeats most sufficiently simple static analyses. A compiler has
to work much, much harder to get useful results. Don't expect anything
anytime soon.

> I've seen this in a previous experience on a Chrome extension where someone
> would seal an object as a form of documentation to express "I need these
> properties to stay in the object". It looked like:
>     function C(){
>         // play with |this|
>         return Object.seal(this)
>     }
> My point here is that people do want to protect their object integrity
> against "untrusted parties" which in that case was just "people who'll
> contribute to this code in the future".
> Anecdotally, the person removed the Object.seal before the return because of
> performance reasons, based on a JSPerf test [3].
> Interestingly, a JSPerf test with a proxy-based solution [4] might have
> convinced to do proxies instead of Object.seal.

Take all these JSPerf micro benchmark games with two grains of salt;
lots of them focus on premature optimisation. Also, seal and freeze
are far more likely to see decent treat than proxies.

But more importantly, I think you get too hung up on proxies as the
proverbial hammer. Proxies are very much an expert feature. Using them
for random micro abstractions is like shooting birds with a nuke. A
language that makes that necessary would be a terrible language. All
programmers messing with home-brewed proxies on a daily basis is a
very scary vision, if you ask me.


More information about the es-discuss mailing list