this (x = sink.bar).apply(sink)
to me is like using apply to undefined ... that is not the equivalent of an "invoke" where the context should be explicit ( e.g. obj.method() ) so is not, in my opinion, a good __noSuchMethod__ case. sink.bar is a getter , if not there, is undefined (unless chained down the __proto__) as it is for any property sink.bar(); is an invoke AFAIK __noSuchMethod__ as never been used as mixin ... I cannot even think about it, but it's possible to recycle the callback for many objects so no need to be able to extract/assign it, imho Not having it and forcing it through a different pattern is **not the same as having it maybe not 100% perfect** ... and I believe latter is also what made JS great in the past. Anyway, I understand nobody wants it so I won't insist any further. br On Wed, Oct 24, 2012 at 5:46 PM, Yehuda Katz <[email protected]> wrote: > > > On Wed, Oct 24, 2012 at 5:16 PM, Andrea Giammarchi < > [email protected]> wrote: > >> But then why such "encouragement" >> https://brendaneich.com/2012/10/harmony-of-dreams-come-true/ ? ( Proxy >> paragraph ) >> >> If __noSuchMethod__ is wrong, what's the point of suggesting a way to >> simulate it through proxies? >> > > __noSuchMethod__ isn't the same problem as my concern about invoke-only > traps. In this case, (x = sink.bar).apply(sink) would still hit the > __noSuchMethod__ method. > > -- > Yehuda Katz > (ph) 718.877.1325 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
