noSuchMethod: "funargs" + "invoke-only-phantoms"

Andrea Giammarchi andrea.giammarchi at
Sat Dec 17 06:11:34 PST 2011

and about last point, maybe objects that implements noSuchMethod should
return something like "unknown" via typeof ... just saying, and simply to
differentiate these objects from others where __noSuchMethod__ is not in

On Sat, Dec 17, 2011 at 3:08 PM, Andrea Giammarchi <
andrea.giammarchi at> wrote:

> Dmitry, addressing a trap fallback is not a good idea plus the average JS
> coder rarely does it ... said that, the moment you are using a method you
> already know this exists so you already know the documentation ( or part of
> it ) so I don't see much hurt there.
> Moreover, the addressing problem is common for all self bound methods and
> the usage of call and apply
> var o {getStuff:function(){return o.stuff}};
> // or o.getStuff = o.getStuff.bind(o);
> Whoever gonna address "getStuff" will have unexpected results with any
> context different from o so, again, whoever is using a method must know at
> least basis of the methods.
> Methods that fallbacks through a trap as noSuchMethod is should not be
> documented as methods because inexistent, these should rather be documented
> under the "magic behavior" explaining in the very first how it works and
> why.
> I don't see many troubles into an invoke-only fallback, I see troubles or
> limits without this possibility.
> The proxy trap is not even an option to me, not to simulate proper
> noSuchMethod behavior where again, typeof o.nonExistentMethod should be
> "undefined", accordingly with __proto__ and getter over that property.
> Are these missing? Cool, there is no such method or property with that
> name so "undefined" and nothing else.
> Ideally, we could find a better way to define objects that implements
> __noSuchMethod__ interface so that developers can be aware in advance of
> potential mistakes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list