brendan at mozilla.org
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-
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
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