Le 30/01/2011 16:58, Tom Van Cutsem a écrit : > > 2011/1/28 David Bruant <[email protected] > <mailto:[email protected]>> > > > > Based on that definition, we could have a stronger definition of > derived traps: > Derived trap are defined as ES code using fundamental traps in > order to respect the forwarding proxy definition. Before going any > further, I'd like to say that it's already the case :-) In my > opinion, that was the rational behind Mark Miller's "coherent > behavior to fall back to" idea of what should be derived or > fundamental. Coherent with what? With what we expect from native > objects. > To solve my problem with proxyArrays, I got rid of all derived > traps definitions in the forwarding proxy code and it worked > perfectly. It could make sense to do exactly the same with the > default proxy forwarding handler, otherwise, people who just want > to implement a fundamental trap (like I did) will have to > reimplement all derived traps depending on the fundamental and it > is very likely that their reimplementation will be the derived > trap default definition. > > > Very interesting observation. So the issue is that the derived traps > of the "default forwarding handler" have two possible default > implementations: > a) forward the derived operation to the 'target' (that is how they are > specified now) > b) implement the "default" semantics in terms of the fundamental > forwarding traps (or equivalently, the default forwarding handler has > no derived traps) > > The problem with a) is that child objects of the default forwarding > handler that override a fundamental trap must actually also override > all derived traps that depend on it. In some cases, the trap > implementor will want to do this anyway since the derived traps may > allow a more efficient implementation, but if not, then indeed the > programmer must either reimplement the default semantics, or delete > the inherited derived trap. > > The problem with b) is that if the "target" object to which the proxy > forwards is itself a proxy p2, then p2's derived traps will never be > called. Instead, only p2's fundamental traps will be called. Things > won't break, but it is suboptimal if p2 has ad hoc (presumably more > efficient) implementations for its derived traps. Presumably, even if > "target" is a native object, option a) is more efficient than > defaulting to the fundamental operations. > > I have no good suggestion yet for how to address both issues. One way > out would be to provide two default forwarding handlers (e.g. a > FundamentalHandler that only defines the fundamental traps (and hence > has b) semantics for its derived traps), and a DerivedHandler that > inherits from the FundamentalHandler that adds the derived traps with > a) semantics). Depending on the required semantics, the programmer can > make his/her custom handler inherit from either one. But maybe this is > just too complex a solution. I do not have a strong opinion on the complexity of the solution, but i find it quite elegant. It solves both problems and keeps being consistent with the handler model by using inheritance.
If I just had one thing to say it would only be about the naming. "DerivedHandler" could confuse programmers who could think that a DerivedHandler only defines derived traps while the derived traps are only the own properties. I think that "Handler" could be kept as the name, only defining derived traps as own properties and inheriting fundamental from FundamentalHandler. David
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
