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

[David Bruant]

Le 23/09/2011 17:45, Tom Van Cutsem a écrit :
> 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>)
True.

> 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 agree and I'm thinking about configuration options for my tool. But
the issue was not necessarily only about my tool.

The bigger issue is that currently if A1 and A2 inherits from B, there
is a way at property-level for B properties to adapt their behavior to
A1 or A2. But there is no way at the object-level (in handlers) to do
the same thing.
WebIDL shows a use case for such a feature at property-level. And i have
the impression that the limitations of this use case require to have an
object-level feature.

If not allowing an object-level adaptation, we are stuck to impose
accessor properties when expecting a per-instance behavior.
The thread starting at [1] shows that WebIDL imposes properties of the
global object to be data properties while dom.js authors would prefer
them to be allowed to be accessors in order to add them lazily.
I admit, this is a different case because we're dealing with the global
object which cannot be implemented replaced by a proxy. But this example
shows that specs may have constraints on the property descriptor types
that may be different from accessor properties.

My intuition is that WebIDL imposes getter/setters since it is the only
way in ES5.1 to have a per-instance behavior while intuition would
rather be to describe all properties as regular data properties which is
what all these getter/setters emulate anyway (see getter and setter
definitions at http://www.w3.org/TR/WebIDL/#es-attributes).

If proxies had this power, the WebIDL spec could be fixed to return data
descriptor as, in my opinion, it should.

David

[1]
http://lists.w3.org/Archives/Public/public-script-coord/2011JulSep/0434.html