[ES Harmony Proxies] Feedback on implementing arrays with proxies
bruant at enseirb-matmeca.fr
Mon Feb 7 14:51:44 PST 2011
Le 30/01/2011 16:58, Tom Van Cutsem a écrit :
> 2011/1/28 David Bruant <bruant at enseirb-matmeca.fr
> <mailto:bruant at enseirb-matmeca.fr>>
> 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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss