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

Dmitry Soshnikov dmitry.soshnikov at
Sat Dec 17 07:27:40 PST 2011

On 17.12.2011 18:08, Andrea Giammarchi 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.

That's it. In designing a language it's better not to build the 
decisions based on "rarely" reasons. Yes, of course we should consider 
percentage of usage of this or that feature, so basically it's good to 
analyze whether is feature is "rare" or "frequent". But in general, we 
can't predict 100% will the method be used in some different ways or not 
-- especially if the user _may_ use it in this way in JS.

Once again, in PHP and others it's much easier to implement things like 
`__call', etc (until 5.3 it even didn't have closures). In languages 
like Ruby it's also easier to implement it, since `' is _already 
a method call_ (or sending a message). There is only method calls in 
Ruby, there are no properties. This is why `method_missing' is logical 

In JS, as well as in Python, there is no method calls, but there is 
getting property values and already after that provide some operations 
on them (in case if the value of the property is a function, you may 
call it). This is, by the way, why Python also doesn't support separated 
`__nomethod__' magic name. In Python, as well as in JS proxies, you have 
to return an "activator" function from `__getattr__'.

> 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.

Yes, this is fair enough. If the user extracts the function for further 
applies, she should know whether a function is generic to be able apply 
it for different `this' values. OTOH, she can do this only for 
optimizations. `' is faster than 
`', so she just saves it to the variable 
and calls.

> 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.

Yes, as I said, I see this way as the only existing to solve the issue 
-- to mention in the documentation, that methods such as 
`find_by_<fieldName>' are magic and that we can't extract them or apply 
in different contexts. If this is acceptable, then this is OK. Then we 
force user to know it and to follow this rule. OTOH, it may be good.

> 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.

Yep, this is also true, and I mentioned it several times in that long 

> 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

This is what nearly Tom proposes with inheriting a special (proxy) 
object. I.e. some object which inherit it will have this _unstratified_ 
noSuchMethod, placed directly on the object (still via proxies, with all 
broken invariants applied), and some do not. OTOH, he also proposed to 
be `Object.prototype' as such a proxy. It can be a good idea, though 
will decrease efficiency.


More information about the es-discuss mailing list