sorry for the typo, this point was 1.2.2.1 yes, invoke that callback via cb.call(object, *"methodName"*, arguments)
On Fri, Dec 16, 2011 at 5:30 PM, Andrea Giammarchi < [email protected]> wrote: > you don't use apply randomly, you use apply for methods or getters knowing > there is a function there. > > __noSuchMethod__ is about NOT HAVING A FUNCTION there and if the property > is not defined apply should fail as well as obj.undefined.apply would > > I still do not understand why we keep mixing up getters with > __noSuchMethod__ behavior which is: > 1. a "method" and not a property invocation ( no obj.inexistent.apply > BUT ONLY obj.inexistent() OR obj[inexistent]() ) > 2. unaddressable since a property that has not been define will always > be addressed as undefined ( or the __proto__ chain value ) > 3. nothing to defer, lazy call, pass through, etc etc ... once again, > noSuchMethod SHOULD cover 1 case, and 1 case only > > obj.iDoNotExistHowCanAnyoneReferAtMeThen(); > > Rules behind the scene, described already in my post: > > Syntax: object.methodName(); // inline invokaction, NO EXCEPTIONS TO THIS > SINGLE CASE > Procedure: > 1. check if object has a property called "methodName" > 1.1 yes, go on and throw an error if it is not callable > 1.2 no, check if the property has a getter > 1.2.1 yes, go on and throw an error if it is not callable > 1.2.2 no, check if the object has a "__noSuchMethod__" fallback > 1.2.2.1 yes, invoke that callback via cb.call(object, > "__noSuchMethod__", arguments) > 1.2.2.2 no, throw an error "undefined is not a method" > > Is above logic really that hard to implement/understand? I don't think so > but it looks like it's me only. > > The described behavior as it is is never ambiguous so what is the problem > exactly? > > Practical example > > var o = Object.defineProperty({}, "test", { > get: function () { > return this.alias; > } > }); > o.alias = function () { > alert(this.message); > }; > o.message = "hello"; > > o.toString(); // __proto__ chain > o.alias(); // property as method > o.test(); // getter > o.noTest(); // __noSuchMethod__ > o.test.call(o); // getter > o.noTest.call(o);// undefined is not a function > > Best Regards > > On Fri, Dec 16, 2011 at 9:54 AM, Dmitry Soshnikov < > [email protected]> wrote: > >> Yep, no doubt, first-class "missed" methods win -- again, because the >> programmer can and has the complete right (by just looking at one line of a >> code) to rewrite simple invoke to `apply' (she don't have to think whether >> it's a virtual method or not). >> >> The only thing I wanted is to reduce broken consequences. Well, or at >> least to be aware about them ;) >> >> Dmitry. >> >> >> On Thu, Dec 15, 2011 at 9:32 PM, Brendan Eich <[email protected]>wrote: >> >>> Agreed there are use-cases for second-class methods, according to style >>> and taste. >>> >>> The impetus for __noSuchMethod__ when I implemented it in 2003 was to >>> support the Smalltalk-based TIBET framework of Bill Edney and Scott >>> Shattuck. They religiously use a Smalltalk style of JS so do not feel any >>> second-class pain. >>> >>> Other styles of JS would definitely feel pain. One size does not fit all. >>> >>> This is why rejecting an invoke trap is not a matter of black and white, >>> IMHO -- it's simply a desire to reduce complexity and see how the result >>> can be used by a library (a standard one, even) to implement something like >>> __noSuchMethod__. >>> >>> /be >>> >>> ----- Original Message ----- >>> From: "Dmitry Soshnikov" <[email protected]> >>> To: "es-discuss" <[email protected]> >>> Sent: Thursday, December 15, 2011 5:48:37 AM >>> Subject: noSuchMethod: "funargs" + "invoke-only-phantoms" >>> >>> >>> Hi, >>> >>> Here is the analysis of current "noSuchMethod" situation implemented via >>> proxies. >>> >>> I summarized that never-ending thread from 2010 ( >>> https://mail.mozilla.org/pipermail/es-discuss/2010-October/011929.html), >>> since guys in JS community started to ask why proxies don't support >>> noSuchMethod. >>> >>> It's written as a small article in a view of JS-code: >>> https://gist.github.com/1481018 >>> >>> Is there something to add? To change probably in the current Tom's >>> proposal? Etc. >>> >>> P.S.: while I was writing the article, I started more to agree on >>> importance of the "extracted funargs" in this case, however the >>> "invoke-only-phantom" methods still and also (as it turns out) are needed >>> to users and required by them. >>> >>> Cheers, >>> Dmitry. >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
