My ECMAScript 7 wishlist

Tab Atkins Jr. jackalmage at gmail.com
Thu Sep 25 13:31:26 PDT 2014


On Thu, Sep 25, 2014 at 12:50 PM, Brendan Eich <brendan at mozilla.org> 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


More information about the es-discuss mailing list