Hi David,
In one of the first discussion about proxies on this list, the question
popped up on whether proxy handlers should implement inheritance (prototype
chain walking) themselves, or whether the engine should take care of this,
only allowing the handler to control the "own" layer. The consensus back
then was to go for the former, as it is more flexible.
If I understand correctly, you are proposing to standardize both. I
understand the rationale, and inheritance-safe proxies may indeed be what
you'd want to use most of the time. But again, in the interest of only
standardizing the essential building blocks: can't the abstraction be
provided as a library?
Cheers,
Tom
2011/3/22 David Bruant <david.bru...@labri.fr>
> 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 (see <
> 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.
>
> That's true.
> 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
> http://wiki.ecmascript.org/doku.php?id=strawman:proxy_instanceof] sooner
> 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 consistency.
> 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.
>
> Cheers,
>
> David
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
