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

[Andreas Rossberg]

On 14 February 2013 19:16, David Bruant <bruant.d at gmail.com> wrote:
> Le 14/02/2013 18:11, Andreas Rossberg a écrit :
>> 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.
>
>     var handler = {set: function(){throw new TypeError}}
>     var p = new Proxy({a: 32}, handler);
>
>     p.a;
>
> It's possible *at runtime* to notice that the handler of p doesn't have a
> get trap, optimize p.[[Get]] as target.[[Get]] and guard this optimization
> on handler modifications. Obviously, do that only if the code is hot.
> I feel it's not that much work than what JS engines do currently and the
> useful result is effectively getting rid of the forwarding overhead.
> Is this vastly over-optimistic?

Yes. Proxies hook into many different basic operations, and there are
many special cases you could potentially optimise for each of them,
many of which don't come for free. I very much doubt that any vendor
currently has serious plans to go down that rathole instead of
spending their energy elsewhere. Certainly not before it is clear how
(and how much) proxies will actually be used in practice.

/Andreas