[[Extensible]]and Proxies (Was: Proxy.isProxy )

David Bruant david.bruant at labri.fr
Mon Jul 18 02:06:37 PDT 2011

Le 18/07/2011 02:58, Brendan Eich a écrit :
> On Jul 17, 2011, at 3:14 PM, David Bruant wrote:
>> I'm only catching up now on this thread. I have indeed started some 
>> work to try to implement an invariant-enforcing implementation of 
>> preventExtension rather than fix+become.
> Just off the top of my head, sorry if I'm misunderstanding: fix based 
> on become is very attractive to VM implementors, because it avoids 
> extra for-life-of-fixed-object costs in the proxy or native code paths 
> that aren't already there with Proxies as proposed and with ES5.
> "becomes" lets the brain-swapped objects do what they do best. There's 
> no hybridization as if by composition using vtbls, if statements, or 
> whatever, that affects proxy codepaths. It's true one could "become" a 
> proxy with the extra code paths, but that's duplicative at some level 
> (not necessarily code inlining, but layering the extra 
> preventExtensions enforcement somehow).
> If the preventExtensions enforcement is the same as the pre-fix 
> overhead for fixed properties, perhaps this is less of an issue.
I was in doubt for some time and I realized that the fixed properties 
required very few checks and these checks turn out to be the same 
performed by some code defined in a way or another in one of the ES5.1 
8.12 algorithms.
By enforcing ES5 invariants, we actually are trying to enforce things 
that are enforced for normal objects already. If you haven't read Tom's 
FixedHandler implementation [1], I encourage you to, because the 
minimalism of it is quite interesting.
Especially, in the get{Own}PropertyDescriptor and defineProperty traps, 
Object.defineProperty is called and as commented, the purpose is to 
(re)use the argument-checking code of this method to let it throw if 
needed. It's extremely generic and future-proof with regard to new sorts 
of property descriptors.
We'll see what the implementation of invariant checking non-extensible 
proxies looks like.

> Sticking with becomes, but (a) distinguishing preventExtensions from 
> seal from freeze and (b) allowing the [[Class]] or ES.next equivalent 
> to be controlled would allow, e.g., Proxy-emulated Arrays that fix to 
> become real (pE'ed, sealed, or frozen) Arrays.
Distinguishing preventExtensions from seal from freeze will still be 
possible with an invariant-enforcing proxy if that's the chosen solution.



More information about the es-discuss mailing list