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.soshni...@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 <bren...@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.soshni...@gmail.com>
>> To: "es-discuss" <es-discuss@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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
