On Thu, Jul 14, 2011 at 12:19 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote:
> I think Mark and I are looking at Proxies from very different perspectives. Agreed. > 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. Absent other costs, that's a fine thing to want. But because of those costs, it was never a goal of the proxies design. > 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 Allen, you and I have been over this, both on list and off. This is simply not true. All the restrictions at the end of 8.6.2 are stated as applying only to host (i.e., non-native) objects only because we did not need to state that they apply to native objects. E5.1 specifies the behavior of native objects in enough detail that we can read the spec and verify that they must obey these constraints as well. > and regardless are questionable in their effect. That's why we have test suites. > 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. I agree that this is a spec bug. We should fix this in the ES5 errata. > 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. > Ok, I admit I haven't paid as much attention to RegExp.prototype.compile as I should, because, thankfully, it is deletable on all major browsers. Where can I read about its cross-browser de-facto behavior? > > 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 y > even though there is no such invariants imposed on built-in objects wrong, as we've discussed numerous times. > and the host object invariants are incomplete and hard to make impossible > to violated. > Host objects are part of the platform. A platform provider is free to violate any part of the spec they like, and there's nothing we can do about it other than to add tests to std test suites to make the violations obvious to the community. > > 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. > Yes. For a start, * That the statechart at < https://bugzilla.mozilla.org/show_bug.cgi?id=630284> represents all the states and transition possible for a property. * 8.6.2, with the clarification that it applies to both native and non-native, and with the [[Extensible]] spec bug that you point out fixed. * The "eternal invariants" from < https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html>. > > 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. > > Until and unless we can all agree on something else, we stick with what we have already agreed to. With our current agreement as a baseline, I am confident we can agree on something better -- like cleaning up the [[Extensible]] spec bug you point out above. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
