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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
