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

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Dec 16 08:33:03 PST 2011


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 <
andrea.giammarchi at gmail.com> 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 <
> dmitry.soshnikov at gmail.com> 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 <brendan at mozilla.com>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" <dmitry.soshnikov at gmail.com>
>>> To: "es-discuss" <es-discuss at mozilla.org>
>>> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111216/e5c7d88d/attachment-0001.html>


More information about the es-discuss mailing list