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

David Bruant david.bruant at labri.fr
Sat Jul 16 06:09:46 PDT 2011

Le 14/07/2011 21:19, Allen Wirfs-Brock a écrit :
> On Jul 14, 2011, at 10:47 AM, Brendan Eich wrote:
>> On Jul 14, 2011, at 10:38 AM, David Bruant wrote:
>>>> In all the cases I can think of, where we want precisely the behavior of an array, why not just use an array?
>>> Of course an array should be used. I think that the current question is rather "can proxies as currently defined can fully emulate arrays?". Being able to fully emulate arrays sounds like an "easy" use case.
>> I agree, and Allen is on the record here too.
>> Fixing an array-proxy to an array could be enough for real-world use-cases, so this may be not a burning practical issue. Indeed it verges on Principle. But it's a good one, and I think we should have a goal (rather than a principle) for cleanly proxying arrays, including non-extensible ones.
>> If this goal is met by saying fixing an array proxy always results in the instance becoming a fixed Array, that could be good enough.
>> I do not think we should say "fix to a non-extensbile object with a length accessor" while we at the same time carefully spec Array length as a data property, precisely to ensure inter-operation. That seems to be telling JS implementors one thing, and (possibly an overlapping group) proxy users another.
>> /be
> I think Mark and I are looking at Proxies from very different perspectives.  I want Proxies to to useful to create a perfect implementation of anything that be specified as a ES built-in object or that might be implemented whether now or in the future as a host object defined in some other programming language.  I hold up ES array objects, string objects, argument objects, functions objects, and various DOM implementations simply as exemplars of such objects that somebody might want to implement using Proxies.
> Historically there never were any real restriction on what such objects can do.
However, all 7 invariants present in the ES5.1 spec all address things
that could not be noticed or changed in JavaScript itself, there was no
way to:
- change configurability
- measure configurability (only non-deletability)
- measure or change [[Extensibility]] (because such a thing didn't exist)
Current invariants seems to be following the general idea of "if I
measure something (non-configurability or non-ensensibility), then, I'll
have some guarantees on what I can/can't do afterward that will hold for
the rest of the program". Since we had no way to measure any before ES5,
I would say that what used to happen before ES5.1 is irrelevant. ES5
implementations not respecting these invariants are more problematic. So
are ES5 constructs that would not respect these invariants too.


More information about the es-discuss mailing list