On Tue, Oct 18, 2011 at 6:45 AM, David Bruant <[email protected]> wrote:
> Hi,
>
> The initial proxy proposal was about to provide "proxy" as an additional
> argument to all traps.
> The current proxy has "target" instead, but still "proxy" for get and set
> traps.
> Regardless of the proposal, I have recently come up with a use case [1]
> where I expressed the need of passing the "receiver" to some traps when the
> proxy is up on the [[Prototype]] chain. (of course, there is still need for
> an agreement that this use case is worthwhile and that there is really no
> way to implement what i want without passing "receiver").
>
>
I think the "reciever" issue is unaffected by the change to direct proxies,
it is still unnecessary if [[GetProperty]] continues to be propogated up the
prototype chain, but necessary if [[Put]] and [[Get]] are propogated
instead. The advantage of the latter is that you don't have to construct a
complete property descriptor for [[Get]]s and [[Put]]s when you only really
need the "get" or "set" attribute, the disadvantage is that it allows
proxies to lie in their Object.getOwnPropertyDescriptor return value's "get"
and "set" attributes, since that is no longer necessarily what is actually
used for [[Get]]s and [[Put]]s.
> I'm afraid this is getting a bit verbose when writing/reading traps. I
> think alternatives should be considered. Of course, putting things directly
> on the handler is out of question to respect proper stratification as
> previously said (by Tom?) on this list.
>
> One idea could be to have a unique optional argument which would be an
> object with 3 properties: "proxy", "target" & "receiver". These aren't
> always necessary, but I think there is no harm in making all of them
> available to all traps.
>
>
The downside of named arguments is that you commit to the names for
eternity, the function author is not allowed to use their own names, such as
abbreviations, and they have to remember the names (as opposed to indexes)
of the arguments. Also, since the other traps have varying numbers of other
arguments, and this argument is proposed as last, this argument would not
appear at the same index, which would not be a problem if the argument were
first. It also seems kind of arbitrary to have some named arguments and
some positional. Destructuring helps with the conciseness of named
arguments though. If changing to named arguments, I would propose a single
Object argument containing all args:
set: function( {name, value, proxy, target /*, receiver*/} )
> Another alternative would be to do natively what we've been doing in code
> which is that when a call is trapped, instead of using the handler, an new
> object is created. This object inherits from the handler and has at the own
> layer the 3 properties. If another trap is traversed, another object is
> created, etc. (this is of course in theory. Engines are free to optimize).
>
> Another close alternative is that instead of an object inheriting from the
> handler, a forwarding proxy with handler as target could be created and when
> performing [[Get]] on this proxy with one of the 3 property names, it would
> return the correct object based on the context.
>
> In the 2 last cases, the proxy would be made accessible from traps with
> "this.proxy", etc.
>
> Thoughts?
>
> David
>
> [1] https://mail.mozilla.org/**pipermail/es-discuss/2011-**
> October/017438.html<https://mail.mozilla.org/pipermail/es-discuss/2011-October/017438.html>
> ______________________________**_________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
Thanks,
Sean Eagan
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
