Brendan Eich brendan at
Sun Aug 17 13:53:49 PDT 2008

On Aug 17, 2008, at 12:54 PM, Yehuda Katz wrote:

> Has any thought been given to adding Object#__noSuchMethod__ or the  
> like (propertyNotFound, method_missing, or whatever it would be  
> called) in ES3.1/Harmony?

ES3.1 is not ES-Harmony. We don't know the future, so 3.1 is just a  
working edition number. It's not far off, since it is a delta to the  
ES3 spec that's mostly additive, and what is added is not different  
from 10% of what's there by lines (guesstimate -- editors may have  
Word-based metrics to clarify).

But it is very late in the day to be adding to 3.1, if it's to be  
interoperably implemented and finalized by next spring. So I think  
__noSuchMethod__ or anything like it must wait for the so-called ES- 
Harmony successor.

That successor, we hope, will not reuse the ES1-3.1 spec formalisms,  
but something clearer and more testable. So work on it proceeds in  
parallel with ES3.1's spec drafting. The current plan is an SML +  
self-hosted built-ins reference implementation that implements ES3.1  
+ whatever the self-hosting needs in the way of magic to support the  

This seems like necessary background, since I've seen several  
requests for features to be added to ES3.1. Never say never, but  
saying "no; next time" is essential to finishing in the desired time- 

> I ask because another commonly requested feature, mixins, is easily  
> implementable in terms of noSuchMethod and getters/setters.

But those are better done without such performance-penalizing  
techniques, and with more abstraction leak-proofing.

> I'm not sure about the implications for implementors or performance  
> (noSuchMethod probably requires a second method lookup pass; I'm  
> not sure how much overhead method lookup has in JS), but being able  
> to override method dispatch itself via a mechanism like this is  
> very powerful.

SpiderMonkey promulgated __noSuchMethod__ (I'm not sure if any other  
engine copied it). __noSuchMethod__ works by waiting until the result  
of obj.method's evaluation in

   obj.method(arg1, ... argN)

is primitive (at which point the call is bound to fail), then getting  
the value of obj.__noSuchMethod__ (as usual; prototype chain searched  
if necessary), then calling that value via

   obj.__noSuchMethod__(id, args)

where args is an Array (for real; not an arguments object)  
constructed from the actual parameters arg1, ... argN.

obj[methodName](arg1, ... argN) calls are also supported, but with  
(obj) method(arg1, ... argN) and the like (unqualified callee name  
variants) are not.

This currently requires an extra object allocation to hold the  
__noSuchMethod__ handler reference and the particular id ('method'  
above) being called, since they would take two slots on a stack-based  
VM that allocates only one for the callee. This cost may or may not  
be tolerable for your application.


More information about the Es-discuss mailing list