On Jul 14, 2011, at 1:19 PM, Mark S. Miller wrote:
> 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 think several of us have been quite consistent in expressing that we are
looking for a mechanism for implementing in pure ES things that currently
require host objects or enhanced object semantics of the sort that historically
has been defined for built-ins such as Array objects. If that was not one of
the goals for Proxies I misunderstood. Perhaps Proxy is not what we need then.
>
>
> 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.
Implementations are free to add new built-in objects (see 4.3.28). Without any
stated requirements for such objects you have no guarantees.
Further more, in writing specification material such as the alternative
internal methods, I was never aware of any requirements that had to be meet by
those implementations other than whatever was necessary to describe the legacy
or new semantics that we were trying to specify. As far as I know, there is no
comprehensive normative specification of invariant that must be maintained by
all objects.
>
>
>
> 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.
No it is not a bug. There was never any consensus on a larger set of
invariants or even as far as I can recall a proposal for such. I don't know
whether or not we would have or in the future can achieve consensus on that.
For now, ES5.1 is what it is and and unless something is clearly internally
inconsistent, unintended breakage from an earlier edition, or breaks long
establish browser behaviors I don't think you can call it a bug.
>
>
> 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?
https://bugzilla.mozilla.org/show_bug.cgi?id=630284
The Microsoft implementation is described in
http://msdn.microsoft.com/en-us/library/ff955265(v=VS.85).aspx but to be sure
what it means you need to write some tests.
These was off-list email earlier among various implementors about this issue.
this is what Luke said at the time:
...
From a quick check, it appears all browsers today violate the "non-writable,
non-configurable properties must not change" rule for these RegExp properties.
Technically speaking, the only mention of that rule I'm aware of in ES5.1 is
8.6.2, and only applies to host objects, so I'm not positive that this is
really violating ES5. But even if it is, that particular rule is a little bit
of a reach anyway - it doesn't seem fundamentally justified by the internal
consistency of the spec, and I'm not sure that implementations can really rely
on it for optimization given that it is easy enough for host objects (and
built-ins) to violate it. With Proxies, it would become even easier to build
objects that violate this rule.
Is the right solution here not just to either:
a) Relax the ES5 rule that non-writable, non-configurable properties must not
change (if it even applies to built-ins)
b) Change the regexp instance properties to get-only accessor properties
As for interoperable behavior more generally - the only disagreement in compile
semantics I have found is that IE and FF return the regexp object from
re.compile(...) as well as modifying the object itself, whereas Chrome does not
return the object. That seems relatively minor, and something that could
easily be made interoperable in either direction. Are there any further known
non-interoperabilities in compile implementations?
Luke
>
> 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.
So we disagree WRT whether the specified behavior of features in current
specification can be extrapolated as imposing limitation on future unrelated
features and specifications.
>
> 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.
We could provide a defined interface mechanism that validates constraints or
limits behavior in a way that guarantees the desired invariants. That's what
Proxies appear to be trying to do, why not do it for host objects. If you can
depend upon host objects actually supporting your invariants why does not
matter whether or not Proxy objects also do so.
>
>
>
> 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 normative specification of valid state transitions is actually 8.12.9, but
that only applied to objects that use that definition of [[DefineOwnProperty]].
Any extrapolation to other situations hasn't been normatively adopted.
> * The "eternal invariants" from
> <https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html>.
We can certainly discuss these, but TC39 hasn't adopted them.
>
>
> 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.
And what we have already agreed to is only what is currently in the ES5.1 spec,
as written. As I expressed above, I don't think there is agreement about
extrapolations of the text to situations that aren't explicitly called out in
the specification.
Sorry, if that seems unharmonious but it seems like the only solid footing we
have.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
