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

[David Bruant]

Le 14/02/2013 18:11, Andreas Rossberg a écrit :
> 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 oread onlyf 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.
     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?

>> 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;
... that's exactly what I said right after :-/
"But that's a JSPerf test and it doesn't really measure the GC overhead 
of extra objects."
"JSPerf only measures one part of perf the story and its nice conclusion 
graph should be taken with a pinch of salt."

> lots of them focus on premature optimisation.
I'm quite aware. I fear the Sphinx [1]. I wrote "might have convinced to 
do proxies instead of Object.seal". I didn't say I agreed. and I 
actually don't.

> Also, seal and freeze
> are far more likely to see decent treat than proxies.
Why so?

> 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.
hmm... maybe.

David

[1] https://twitter.com/ubench_sphinx