Le 30/07/2013 18:57, Allen Wirfs-Brock a écrit :
So far in ES<=6 dealing with such private data slots is something that
could be treated in a relatively ad hoc manner within the ES spec. and
by implementations. But in ES7 we really want and need user definable
per instance private data. The issues we are encountering here are a
precursor of the issue we will see down the line and what we do now
may constrain what we can do later.
I could not agree more. Should proxies be deferred waiting for private
data, then?
Or, maybe they can be put in quarantaine in some way. For instance,
making the constructor throw if the target isn't a regular object.
That's for the time being until the "private state" (whether "private
internal slots" or user data) is sorted out. A max-min sort of proxy, I
guess.
...
For a broader discussion of the use of [[Class]] in ES5 see
https://docs.google.com/document/d/1sSUtri6joyOOh23nVDfMbs1wDS7iDMDUFVVeHeRdSIw/edit?hl=en&authkey=CI-FopgC&pli=1
Cases are annoyingly numerous, but finite. A test suite can go a long
way. I heard the test suite is moving to Github :-) Only missing is
an extensive doc of the test framework.
Tests are normative and you can't write a valid test suite in the
absence of an accurate specification.
I was answering to your concern about built-in implementations and
memory safety hazard. If a test suite contains a good share of tests to
exercise how built-ins react when passed proxies as arguments (including
'this'), this would provide some level of confidence that the
implementations aren't too memory unsafe.
What the tests exactly returns will of course have to be determine by an
accurate spec, no doubt here.
I was thinking of tests as a coverage method here, not as a conformance
tool.
So self-hosted code can distinguish an actual array from a
proxy, that's not an issue.
Non-privileged code being able to distinguish an array and a
proxy for an array is more worrisome.
I go the other way, in general there should be nothing special
about "self-hosting code". Perhaps the phrase is even
misleading. What I'm really saying that there should be no
particular reason that anything other than the most primitive
elements of the the ES built-ins can't be expressed in ES code.
A proxy with an Array as its target is not an Array. Whether
such an object is substitutable for an Array instance is high
dependent on the details of its handler and other aspects of its
implementation. Also please see
http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api which
address related issues.
This is not enough.
this-binding ("proxy.getMonth()" when the target is a Date) is only
half of the story. The other half remains unadressed
("Date.prototype.getMonth.call(proxy)"). Exotic objects aren't always
used as "this" value. This is exactly Tom's feedback actually.
We need the same solution for both cases (this and non-this usage of
methods).
I also raised this objection and it is what led to the recent update
to the virtual object API referenced above. What that change does is
make it easier for ES programmer to create proxies that behave in this
manner.
But, in the end we could not come up with a solution for the
Date.prototype.getMonth.call(proxy) issue. The [[Invoke]] MOP
operation/trap was added to minimize the actual occurrence of this
scenario. You can't use 'call' to force a built-in to operate upon
the wrong kind of object.
The introduction of [[invoke]] in this particular context might be an
instance of "may constrain what we can do later". Specifically, it may
collide and feel duplicate if a more generic solution is found for
Date.prototype.getMonth.call(proxy); a more "useful" example of which is
Set.call(proxy).
The (granted implicit) model of "a proxy for exotic object X
is seen by all algorithms as an exotic object X" feels simpler
even if it means that a proxy might not act as an internal
algorithm expects.
memory safety hazard. Every place that checks for "is O an
exotic X object" would have to have a subsequent "is O a Proxy
whose target is an exotic X" and take different code paths. If
you screw it up, you may have memory safety issues.
That's an implementation hazard; not sure what your point is here.
The major of such test in the spec. are abstracting over such
implementation hazards. That's why they are there.
Let's let implementors deal with implementation issues. Let's just
make sure the spec isn't impossible or too high barrier to implement.
A test suite will do the rest. Let's care only for tests that make
sense when authoring.
Implementors are free to dive in here to say I'm wrong and why.
ES spec. largely exists to constrain how implementors deal with such
issue in order to guarantee that different implementations have
observably identical behavior.
How did the discussion shift from "memory safety issue" to "observably
identical behavior"?
In any case, I agree with you.
I think you are glossing over real issues that require real design
thinking and which probably can't be addressed until ES7.
I think I understand the real issues :-) I don't have a idea to solve
them and even less an idea TC39 would agree on, but I understand them.
I feel that the [[invoke]] proposal is an attempt to get the maximum out
of proxies without addressing them and I wonder whether it would be
better to wait.
I complete disagree WRT tests. Tests written without reference to some
normative specification are just a reflection of how their developer
thinks the system should work.
Again, I thought of tests as a coverage tool more than a conformance one
(though obviously, testing conformance along the way is obviously a nice
property, but has to wait for an actual spec)
...
Something has to be given up. And giving up on
indistinguishability would defeat the purpose of proxies (and
the expectation as feedback on Tom's library suggests).
You suggestion is? My point is ES internal branding, whether you
call it "check for exotic XXX object", "check for the[[XXX]]
internal data property" or check if [[Class]] == "Array" h does
not work with the Direct Proxy default handler semantics.
Is there a handler semantics with which it can fully work? That's all
is needed.
The ForwardingHandler semantics is close to what you want.
The part I'm being insistent on is the delta between what this handler
enables and what it does not.
The use of 'this' has been special-cased. I understand the biais that
leads to this decision, but I don't think it's a good rationale.
I think it's an equivalent biais than the one of the original Proxy
design where the [[prototype]] was passed to the proxy.create function
as if the [[Prototype]] internal property was that special in the MOP.
'this' is the 0th argument of functions (and .call shifts the order
making this statement false in absolute terms), there is no good reason
to give it a special treatment.
But it still doesn't work the way you would like for direct "call"
invocation or for things like Array.isArray. The base issue for
either of these is that they don't indirect through the proxy handler
and hence the handler doesn't have an opportunity to replace the proxy
reference with the target reference.
Wouldn't replacing the proxy reference for the target reference be
violating stratification?
Per exotic type traps would solve the issue generically, I think.
Do you have new use cases, that motivate the design of an enhanced
Array.isArray?
I cited membrane transparency a couple of times. Tom seems to agree.
Others have opinions?
It would be quite easy to extend Array.isArray(obj) so that it
delegated back to obj with a @@areYouAnArray method such as we are
doing with @@isRegExp in certain places. However, if we do that you
loose support for the original Array.isArray use case because any
object could decide to return true from Array.isArray.
...
If, for instance, you have an "areYouAnArray" trap that only works if
the target is an Array (recursive definition with actual arrays as base
case), then Array.isArray isn't spoofable by any object.
Mark and Tom once used a expression about direct proxies. Something like
"invariant forwarding" or something like that, where the target imposes
restrictions on the handler. This could be extended to exotic objects by
adding per exotic type only traps.
This thread feedback brings new data and it seems that the current
handler offering isn't enough (and I understand can't be).
yup
Glad we agree here :-p
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
