Le 17/10/2011 15:21, Sean Eagan a écrit :
Hi David,
So basically the argument for removing the receiver argument is simply
that according to ES5 semantics, the "getPropertyDescriptor" trap, not
"get" / "set", should be called when proxies are encountered via
prototype climbing due to a [[Get]] or [[Put]]. If the pd returned by
"getPropertyDescriptor" contains a "get" (for [[Get]]s) or a "set"
(for [[Put]]s), it will be invoked with |this| bound to the receiver,
and thus the receiver is in fact available. Thus, the "get" and "set"
trap would only be invoked for own property access, not inherited. The
reason you can't currently implement it
What is "it" refering to? The |this| binding of get and set traps?
Because this can be implemented. Since the get and set traps get
(incorrectly) called with the (correct) receiver, the binding can be
done at the prototype level.
And my inherited events use the same Firefox feature/bug to be implemented.
without the receiver argument is because the Firefox implementation
calls "get" and "set" instead of "getPropertyDescriptor".
If Firefox called the getPropertyDescriptor, i would return something
like {configurable:true, enumerable:true, event:true}. Actually, I'm not
sure this is desirable. Regardless, if i am returning something else
than currently supported property descriptors, the engine can't have the
behavior I expect, hence I wish to have control over what happens.
Not sure what the V8 implementation does.
The other option would be to change from the ES5 semantics such that
[[Get]] and [[Put]] ([[Set]] ?) calls are propogated up the prototype
chain, instead of [[GetProperty]] calls, but I'm not sure what the
ramifications of that would be.
Interestingly, your intervention makes me realize that current [[Get]]
and [[Put]] definition only knows what to do with data and accessor
property descriptors. I think that this prevents from inventing new
typed of data descriptors from being inherited.
It seems that if we want to allow new kinds of property descriptors and
these properties to be inherited, [[Get]] and [[Put]] semantics must be
changed.
Thanks,
David
On Sun, Oct 16, 2011 at 6:00 PM, David Bruant <bruan...@gmail.com
<mailto:bruan...@gmail.com>> wrote:
Le 12/10/2011 15:38, David Bruant a écrit :
> (...)
>
> _Future work_
> 1) see how to deal with inherited events
So, I've been working on that. Updated code at
https://github.com/DavidBruant/HarmonyProxyLab/tree/master/EventedObject
(index2.html
<https://github.com/DavidBruant/HarmonyProxyLab/tree/master/EventedObject%0A%28index2.html>
for test case).
Interestingly, in order to be able to implement inheritance, I
used the
receiver argument of the get trap. I know that it was very close to
being removed completely [1], and that Firefox is incorrectly
(according
to the ES5 definition of [[Get]]) calling the get trap on the
prototype
but I'd like to argue to keep the receiver argument (exact traps to be
defined though).
As can be seen in my get trap, I use the 'receiver' argument for
binding
the event. I actually do not see any other way to implement it. I
don't
see a way for the event to know what to bind to when firing if the
receiver isn't passed to a trap of the event when this one is on the
prototype of the receiver.
I'm not sure which trap should have this argument. I have showed
one use
case, but maybe others would need the receiver with the
getPropertyDescriptor trap call recursively?
To all traps related to inheritance?
David
[1]
http://wiki.ecmascript.org/doku.php?id=strawman:proxy_drop_receiver
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
--
Sean Eagan
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
