2011/5/26 David Bruant <david.bru...@labri.fr>
> Le 26/05/2011 18:44, David Flanagan a écrit :
> > On 5/26/11 6:51 AM, Sean Eagan wrote:
> >> Is think it would beneficial to replace all this.* calls in the
> >> default trap implementations with Object.* methods and syntax that
> >> subsequently triggers the this.* calls. This would guarantee that
> >> none of the internal object semantics are being missed, and
> >> implementations could still optimize just as easily.
> We have been discussing whether this.trap was equivalent to Object.trap
> (shorthand notation) and the conclusion was that there was no way to
> distinguish both cases. I think there actually is.
> If, in a handler, I do "this.defineProperty(23, {value:1})", there is no
> conversion of the first argument to a string while there is if I
> internally call "Object.defineProperty(proxy, 23, {value:1})"
> There are probably other such cases.
>
> And I agree with Sean. this.trap calls should be replaced with Object.*
> calls
>
The current API doesn't allow this as changing |this.*| to |Object.*|
requires the handler to have access to the |proxy| in all traps. But if <
http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy> is
accepted, this seems like a good suggestion.
> > With specification text "as if by calling the primordial Object.*
> > function"? So that user modifications to Object.* are not observable?
> I would argue so.
> (by the way, ES5 terminology says "built-in" where you say "primordial")
>
>
> > Wouldn't that mean that a pure-JavaScript implementation of the
> > default traps would not be possible from a module that could not run
> > at interpreter startup? (That may not be a goal that anyone has, of
> > course.)
> Is it a goal at all?
> There are plenty of things that are not possible anymore after one
> starts messing around with built-in. I wouldn't be shocked by adding
> this one.
> I will always be in favor that derived traps should be implementable
> with pure JS in a fresh environment, but when the environment isn't
> fresh, it don't think it's worth worrying about such a guarantee.
>
I agree. I think it would be good to specify the built-in implementation of
derived traps to always invoke the built-in Object.* methods. This allows
engines to fully optimize. It is still possible for JS programmers to
faithfully implement the default behavior in JS, given a consistent
environment (consistent meaning here that Object.* methods may even have
been monkey-patched, but remain faithful to their ES5 semantics).
> > Personally, I think that proxies would be easier to reason about if no
> > distinction was made between fundamental and derived traps.
> Based on my experience with proxies, there are very few cases which
> really require to re-implement all traps. Reimplementing the
> fundamentals and letting the engine handle inheritance + hasOwn trap is
> handy.
>
>
> > I'd put that distinction in an abstract Proxy.Handler class and then
> > rename the current Proxy.Handler to Proxy.ForwardingHandler.
> What do you call a "class" is is a constructor with some arguments?
> Could you provide a code snippet of how you'd see it work.
>
> Also, I think that this strawman
> (
> http://wiki.ecmascript.org/doku.php?id=strawman:derived_traps_forwarding_handler
> )
> is a first step toward what you're asking.
> I've also raised the idea of renaming what is currently called
> Proxy.Handler. It's still in discussion I think. I remember that Tom had
> an idea, but I don't remember which.
>
My latest suggestion was to rename Proxy.Handler to Proxy.Forwarder
(Proxy.ForwardingHandler is a mouthful).
The idea of the cited strawman would be that Proxy.Forwarder inherits from
Proxy.BaseForwarder. BaseForwarder implements a forwarding implementation of
all the fundamental traps. Forwarder then adds a forwarding implementation
for the derived traps. Programmers can then create handlers that inherit
from either one of these prototypal handlers, and override only a select
number of traps, relying on the inherited implementation for the other
traps. This seems to be in line with what David F. is proposing.
Cheers,
Tom
>
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
