On Thu, Sep 25, 2014 at 12:50 PM, Brendan Eich <[email protected]> wrote: > Tab Atkins Jr. wrote: >> If you try to add it in a targeted way in the middle of >> your hierarchy, it requires either __proto__ hacking, something like: >> >> class superclass {...} >> ... >> x = makeNSPProxy() >> x.__proto__ = superclass() >> class subclass extends x {...} > > > (In such code, you need x to be a function with .prototype that is the > proxy, as just up-thread at > > https://mail.mozilla.org/pipermail/es-discuss/2014-September/039565.html > > but no big deal.) > > Yes, the proxy's get handler must deal with superclasses other than Object, > if that's required. > > The requirements aren't clear (we're probably assuming something that > doesn't match what developers want in full), but that's the point: TC39 is > not the library designer droid you're looking for. > >> On the other hand, a magic property can be placed exactly where you >> want it, without any difficulty. > > > No one made a coherent proposal for the magic property. It was not clear > from Andrea's latest post, where he even allows > > "I also think Proxy already gives us a way to work around the > `__noSuchProperty__` "issue"" > > that this wish-fulfillment __noSuchProperty__ magic property does not have > to handle superclass delegation. > > So please define the magic property fully before recommending it as better > than the Proxy-based library approach. How would it work? The engine calls > the function value of this magic property only when the object on which it > is set has no such *own* property? > > If so, then the handler function must not throw if some superclass contains > the wanted name. Just as the Proxy get handler I showed does for > Object.prototype. > > If not, then does the magic property trigger only when the object on which > it is set *and every object on its prototype chain* has no such property? > That is a bit nasty on the JS engine optimized lookup side, but perhaps > implementors should work harder so users don't have to. > > Is that what you're proposing? Then we should summon optimizing engine > hackers. I've cc'ed one :-P.
Yes, that is what I'm proposing. If lookup fails completely (reaches Object.prototype without finding the named property), it then does a second lookup for the magic NSP property, and if it finds it, executes it with the property name, returning the return value as the result of the original lookup. I don't understand how you inferred from Andrea's post that "this wish-fulfillment __noSuchProperty__ magic property does not have to handle superclass delegation.". At minimum it needs to handle delegating to the object's own prototype (it would be a pretty poor NSP if it couldn't handle methodMissing use-cases as well), and I don't think there's a reasonable case to stop at just one level up; doing so would make this very fragile to refactoring your hierarchy, as methods show up as missing or not depending on where they end up in the class hierarchy. ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
