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.
I understand and actually strawman:handler_access_to_proxy will help out
with this flexibility. However, currently "implementing inheritance"
(re-implementing current inheritance or new inheritance patterns) is
limited or rather slightly biaised since Object.getPrototypeOf and
instanceof are too rigid. My personal feeling on the current approach
with instanceof ('hasinstance' trap for the right-hand side constructor)
is that it won't be usable in practice (because you need ot mark or list
objects).
I invite you to read the two first paragraphs of my initial message
"[Harmony proxies] Proxies, prototype chain and inheritance". They
provide the basics of an alternative to the instanceof strawman. I won't
pretend it's better on all aspects, but I think it both approaches are
worth discussing. Maybe a solution in between could also be a decent
solution too, I don't know.
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?
My current feeling is that the inheritance issues will prevent us from
providing a unique consistent API from which all use cases can be
provided as a library. I may have been rushing a bit the discussion.
Let's see how the proxy inheritance topic goes with discussions and
experiments and we'll be able to answer your question.
Bests,
Le 23/03/2011 11:26, Tom Van Cutsem a écrit :
> 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.
I understand and actually strawman:handler_access_to_proxy will help out
with this flexibility. However, currently "implementing inheritance"
(re-implementing current inheritance or new inheritance patterns) is
limited or rather slightly biaised since Object.getPrototypeOf and
instanceof are too rigid. My personal feeling on the current approach
with instanceof ('hasinstance' trap for the right-hand side constructor)
is that it won't be usable in practice (because you need ot mark or list
objects).
I invite you to read the two first paragraphs of my initial message
"[Harmony proxies] Proxies, prototype chain and inheritance". They
provide the basics of an alternative to the instanceof strawman. I won't
pretend it's better on all aspects, but I think it both approaches are
worth discussing. Maybe a solution in between could also be a decent
solution too, I don't know.
> 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?
My current feeling is that the inheritance issues will prevent us from
providing a unique consistent API from which all use cases can be
provided as a library. I may have been rushing a bit the discussion.
Let's see how the proxy inheritance topic goes with discussions and
experiments and we'll be able to answer your question.
Bests,
David
>
> Cheers,
> Tom
>
> 2011/3/22 David Bruant <david.bruant at labri.fr
> <mailto:david.bruant at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110323/ad12c7cf/attachment.html>
Le 23/03/2011 11:26, Tom Van Cutsem a écrit :
I understand and actually strawman:handler_access_to_proxy will help out with this flexibility. However, currently "implementing inheritance" (re-implementing current inheritance or new inheritance patterns) is limited or rather slightly biaised since Object.getPrototypeOf and instanceof are too rigid. My personal feeling on the current approach with instanceof ('hasinstance' trap for the right-hand side constructor) is that it won't be usable in practice (because you need ot mark or list objects). I invite you to read the two first paragraphs of my initial message "[Harmony proxies] Proxies, prototype chain and inheritance". They provide the basics of an alternative to the instanceof strawman. I won't pretend it's better on all aspects, but I think it both approaches are worth discussing. Maybe a solution in between could also be a decent solution too, I don't know.
My current feeling is that the inheritance issues will prevent us from providing a unique consistent API from which all use cases can be provided as a library. I may have been rushing a bit the discussion. Let's see how the proxy inheritance topic goes with discussions and experiments and we'll be able to answer your question.
Bests,
Le 23/03/2011 11:26, Tom Van Cutsem a écrit : > 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. I understand and actually strawman:handler_access_to_proxy will help out with this flexibility. However, currently "implementing inheritance" (re-implementing current inheritance or new inheritance patterns) is limited or rather slightly biaised since Object.getPrototypeOf and instanceof are too rigid. My personal feeling on the current approach with instanceof ('hasinstance' trap for the right-hand side constructor) is that it won't be usable in practice (because you need ot mark or list objects). I invite you to read the two first paragraphs of my initial message "[Harmony proxies] Proxies, prototype chain and inheritance". They provide the basics of an alternative to the instanceof strawman. I won't pretend it's better on all aspects, but I think it both approaches are worth discussing. Maybe a solution in between could also be a decent solution too, I don't know. > 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? My current feeling is that the inheritance issues will prevent us from providing a unique consistent API from which all use cases can be provided as a library. I may have been rushing a bit the discussion. Let's see how the proxy inheritance topic goes with discussions and experiments and we'll be able to answer your question. Bests, David > > Cheers, > Tom > > 2011/3/22 David Bruant <david.bruant at labri.fr > <mailto:david.bruant at 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110323/ad12c7cf/attachment.html>