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
place.
On Sat, Dec 17, 2011 at 3:08 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> 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
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
