[Harmony proxies] Inheritance safe proxies (was: [Harmony proxies] Proxies, prototype chain and inheritance)
david.bruant at labri.fr
Tue Mar 22 09:15:34 PDT 2011
Le 22/03/2011 12:58, Tom Van Cutsem a écrit :
> Another way of solving the inconsistency I see in providing the 6
> "prototype-climbing" traps ("getPropertyDescriptor",
> "getPropertyNames", "has", "get", "set" and "enumerate") and
> protecting Object.getPrototypeOf and instanceof could be to
> provide a softer version of proxies where these traps wouldn't be
> provided. Prototype-climbing internal methods would be delegated
> to the ECMAScript engine with the default behavior they have on
> objects (but still calling own traps when their algorithm requires
> them to). By design of this softer version, proxy writers would be
> ensured that inheritance will be done properly for them and they
> don't have to worry about it. They would just have to take care of
> the own properties "layer". (This paragraph is a slightly
> different topic. If you feel it requires its own thread, feel free
> to fork)
> I think this "softer version" already exists. If we can get agreement
> to turn getPropertyDescriptor and getPropertyNames into derived traps
> <http://wiki.ecmascript.org/doku.php?id=strawman:proxy_derived_traps>), then
> all of the prototype-climbing traps become derived. As such, proxy
> writers that stick to overriding only fundamental traps will only need
> to take care of the "own layer", and inheritance will be taken care of
> by the default implementation of the derived traps.
However, I feel there is something more that may require the separation.
Before going any further, I'd like to rename what I called "soft
proxies" as "inheritance safe proxies", because that's what they would
be by design. They would keep all (no exception) prototype chain-related
invariants. Under the light of what Mark Miller said ("I just heard from
Brendan today that Andreas Gal has encountered some DOM emulation issues
that might make us want us to consider [the adoption of
rather than later."), it appears that some prototype chain related
invariants (relationship between instanceof and the internal
[[Prototype]]) will disappear, because they prevent from implementing
multiple inheritance while keeping consistency with instanceof.
As I said, one inconsistency I currently see in the Proxy API is that
proxies through proto-climbing traps can fool all inheritance
mechanisms. Meanwhile, Object.getPrototypeOf and instanceof are kept
safe (well, maybe not for long for instanceof). Basically, while the
entire own properties API is fully trappable, the inheritance API is
half trappable half locked. It gives me the feeling of something wrong.
Spliting in two APIs with one being "inheritance safe proxies" and the
other giving more power on inheritance (the direction current proxies
seem to follow) could be one solution to have two consistent APIs
instead of one.
One interesting difference is that I think the issue of data validation
and massaging would have two different answers for both approaches. In
current proxies, proto-climbing traps default behaviors are just
conviniences in order to reduce the number of traps to be written.
That's the reason why I argue that if you want to define your own
internal consistency, you can get rid of default derived traps behaviors
by overriding them. Consequently, data validation+massaging would just
be "on your way", preventing you from fully defining your own internal
On the other hand, for inheritance safe proxies, this would be a
different story. The inheritance internal methods have expectations and
you cannot change that since you could not override them. You would have
to fit within the model provided by regular objects and inheritance.
Consequently, I would argue, for that case that data
validation+massaging is necessary.
After reviewing all the examples, it has given me the impression that
all without exception could be implemented with inheritance safe
proxies. With the expection of full forwarding proxies if these forward
to a full proxy and attempts (not on the wiki) to implement multiple
inheritance which require a different get trap. Otherwise, all examples
currently using the get trap could achieve the same things with the
getOwnPropertyDescriptor. It would be slightly more verobse though.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss