My ECMAScript 7 wishlist

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

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


More information about the es-discuss mailing list