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'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.
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
