[[Extensible]]and Proxies (Was: Proxy.isProxy )
allen at wirfs-brock.com
Thu Jul 14 12:19:57 PDT 2011
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.
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. The DOM and RegExp.prototype.compile demonstrate this. The host object object restrictions added in ES5 don't apply to built-in objects and regardless are questionable in their effect. For example, the ES5 spec says "Host object may implement these internal methods in any manner unless otherwise specified" and "The [[DefineOwnProperty]] internal method of a host object must not permit the addtion of a new property...if the [[Extensible]]...has been observed...to be false". So, in that case [[DefineOwnProperty]] can't add a new property but [[Delete]], or [[Get]], or [[DefaultValue]] or any other the internal methods could as nothing specifies that they can't. Finally, in adding the restrictions to ES5 I don't think there was any serious effort to see whether or not the restrictions were consistent with what host objects actually did. Certainly they are not consistent with the commonly implemented behavior of RegExp.prototype.compile.
My sense is that Mark has some specific invariants that he wishes were guaranteed in ES implementations and he wants to make it impossible to violate those invariants using Proxies even though there is no such invariants imposed on built-in objects and the host object invariants are incomplete and hard to make impossible to violated.
If we really want to do this, then we need to really define a complete and self consistent set of invariants that we are willing to apply to all objects (include built-ins and host) now and into the future. Also in designing any guarantees into Proxies we need to make sure that they they do not impose any additional restrictions other than what is actually stated or implied by the agreed upon invariants. Conservative guarantees that go beyond the invariants are not acceptable. If we were going to enforce such upon Proxies then we need to also enforce the same for built-in and host objects.
Personally, I'm skeptical that we can agree upon such a set of invariants that are compatible with the legacy language and DOM. I'm also an skeptical of the need to do so for Proxies or for built-in and host objects. But, if we want to go for it, then we should proceed and try to define the universal object invariants and see if we can reach consensus on accepting them. If we can't, then we shouldn't be restricting Proxy semantics based upon some assumed invariants.
More information about the es-discuss