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

Mark S. Miller erights at google.com
Thu Jul 14 13:27:17 PDT 2011


On Thu, Jul 14, 2011 at 1:19 PM, Mark S. Miller <erights at google.com> wrote:

> On Thu, Jul 14, 2011 at 12:19 PM, Allen Wirfs-Brock <allen at 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.
>

Oops. Copy-paste error. Should be <
http://wiki.ecmascript.org/doku.php?id=es3.1:attribute_states>.



> * 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
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110714/0f16705b/attachment.html>


More information about the es-discuss mailing list