[Harmony proxies] Thoughts on the almost-dead "receiver" argument

[Tom Van Cutsem]

Hi David,

Even without a |receiver| parameter, a Proxy used as a prototype could still
access the receiver for accessor properties and function-valued data
properties (cf. the last code snippet at <
http://wiki.ecmascript.org/doku.php?id=strawman:proxy_drop_receiver>)

Of course, it would not work for data properties in general, which seems to
be what you need here.

I'm not sure whether this use case is sufficiently convincing to adapt
proxies though. Accessor properties seem to be the right tool for this kind
of behavior. The problem here is that you don't want your visualization tool
to cause side-effects by invoking getters. But that's not a strong guarantee
anyway: if your visualization tool encounters a proxy, it will invoke traps
which could also cause side-effects. So why not bite the bullet and have
your visualization tool invoke the getter?

I do agree that if we would reintroduce |receiver|, we should add it to all
proto-climbing traps for consistency.

Cheers,
Tom

2011/9/18 David Bruant <david.bruant at labri.fr>

> Hi,
>
> I recently filed a bug on Firefox [1] regarding the fact that i find the
> prototype chain of event objects to be messy (half of the problem is
> Firefox specific, the other half is standard as per WebIDL). In this
> page [2], click anywhere to see a click event prototype chain (top-left
> object is the own layer, then, in reading order, its prototype, then its
> prototype, etc. Initial screen is the global object).
>
> On the prototype chain are all event properties (type, target,
> eventPhase, etc.) which all appear on the prototype chain and as
> getter/setter pairs as per WebIDL [3] [4].
> In the long term, I wish my vizualisation tool to be used live to take
> snapshots of an object (and allow to visually compare 2 states of an
> object at 2 different times, for instance), so I made the choice to not
> call getters in order to avoid unexpected side effects. This goes with
> the constraint that in the very case of WebIDL, i can't retrieve the
> type of the different properties nor the value. Unlike in Chrome which
> does not follow WebIDL, but provides a better visualization (in my
> opinion).
>
> The discussion in the bug revealed that the WebIDL choice is made in
> order to allow composition: "Making the properties live on the prototype
> allows hooking them on all objects of a given type, which is something
> web developers commonly want.". Consequently, the properties must remain
> in the prototype object representing each interface.
> Given this constraint, it becomes compulsory in pure ECMAScript 5.1 for
> properties to be setter/getter pairs in order to return a value per
> object inheriting from the interface-prototype-object (thanks to the
> |this| binding).
>
> In an ES5.1 + proxies world, it could be imagined that
> interface-prototype-object could be proxies returning a different /data/
> property descriptor based on the "requesting" object. Both responding to
> the WebIDL constraint and providing the ability to automatically
> retrieve value and type.
>
> Unfortunatly, there is currently no way to have per-inheriting object
> behavior as there is no way to pass the inheriting object. There was
> with the "receiver" argument of get and set traps but it's on its way to
> be killed. Anyway, it wouldn't be enough. I think that all
> proto-climbing read traps (getPropertyDescriptor, getPropertyNames, has,
> get, enumerate) should have access to the requesting/receiver object.
> It's more than necessary for the use case that i raise, but sounds
> consistent to me.
> In accessor properties the receiver object is provided as a |this|
> binding. This is not possible in proxy traps as |this| is used to denote
> the handler object. Consequently, an additional argument seems to be the
> way to go.
>
> David
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=684696
> [2] http://davidbruant.github.com/ObjectViz/
> [3] http://www.w3.org/TR/WebIDL/#interface-prototype-object
> [4] http://www.w3.org/TR/WebIDL/#es-attributes
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110923/4e2d2050/attachment-0001.html>