[Harmony proxies] Thoughts on the almost-dead "receiver" argument
david.bruant at labri.fr
Sun Sep 18 12:56:35 PDT 2011
I recently filed a bug on Firefox  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 , 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  .
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
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.
More information about the es-discuss