Le 26/11/2012 21:39, David Bruant a écrit :
Le 26/11/2012 20:59, Tom Van Cutsem a écrit :
2012/11/26 David Bruant <[email protected] <mailto:[email protected]>>
We could define a symbolic value (like StopIteration for
iterators) that would mean "forward to target". By essence of
what forwarding to the target means, there would be no need to
perform the least invariant check. We can call it ForwardToTarget :-)
I think we've previously entertained a similar proposal when a
handler was encountering the .public property of a private property
it didn't know, and then wanted to signal to the proxy "I don't know
this private name, please forward".
True. I had the feeling the idea wasn't entirely knew, but I couldn't
recall what was the inspiration for it.
I recall one issue was that you'd really want a unique token per trap
invocation, which costs.
I don't understand why a unique token per trap invocation would be
necessary.
I still don't understand this point.
I've gone spelunking. I've found:
* the wiki page [1] (reflecting July meeting) which mentions that
returning undefined would express "I don't know the private name, please
forward"
* Confirmed on July 31st [2].
* Introduction of the idea of putting the verification of known names
somewhere else than for each trap return [3]. Some discussion in between
about this idea. Introduction of the idea of adding a third argument [4]
after which I think stops all discussions about returning something in
traps to prove knowledge of a private name or forwarding when not knowing.
I don't remember the point about a token per trap invocation and I
haven't been able to find it (but I haven't read everything).
In any case, for "throw ForwardToTarget", I don't see why it would be
necessary. It seems it would work unambiguously with meta-handlers, with
target-as-a-proxy or with manipulate-any-other-proxy-inside-a-trap
(which target-as-a-proxy is an instance of).
David
[1]
http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies#discussed_during_tc39_july_2012_meeting_microsoft_redmond
[2] https://mail.mozilla.org/pipermail/es-discuss/2012-July/024246.html
[3] https://mail.mozilla.org/pipermail/es-discuss/2012-July/024256.html
[4] https://mail.mozilla.org/pipermail/es-discuss/2012-August/024313.html
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
