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

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Dec 16 21:56:28 PST 2011


if both V8 and SpiderMonkey will follow that logic to trap invoke-only
method, I'll do my best to promote and explain how it works and why
addressing anyhow does not make sense since there is nothing to address
being inexistent.

That case would be covered eventually by no such property but this one
specially is trivial with Proxies, the method isn't.

Te shouting is me being lazy with bold and stars trying to underlying
common misconception I have read around about what "problem" noSuchMethod
should bring, in my opinion non of them as long as the behavior is well
defined and clear which is, to me, the case since ever.

Good to know that at least SpiderMonkey is not planning to drop it

Best Regards

On Fri, Dec 16, 2011 at 5:59 PM, Brendan Eich <brendan at mozilla.com> wrote:

> I don't think SHOUTING helps your argument.
>
> The key point is whether and how any user of an abstraction can know that
> a given method is first- or second-class. Some frameworks such as TIBET use
> second-class methods only.
>
> Others (E4X, ECMA-357 comes to mind -- users did and do trip over its
> invoke-only methods) could segregate and document methods as to which can
> be extracted and called later with an appropriate |this|, and which are
> invoke-only.
>
> But arguing your conclusion that __noSuchMethod__ is only about the latter
> case of NOT HAVING A FUNCTION doesn't help. It's a circular argument.
>
> Abstractions of the O-O varieties have different philosophies about
> methods, but when applied to JS, the cross-browser libraries do not say
> "you have to know if this method is real or virtual." People have not built
> much on __noSuchMethod__ since it's only in SpiderMonkey. We lack
> experience in-the-large with it.
>
> On this basis, I'm still happy to see method-missing traps implementable
> on top of direct proxies. Users will soon be able to experiment with such
> libraries in SpiderMonkey and V8. Then we can see what we've learned. If
> you are right, it'll be trivial to standardize one of these libraries, or
> even make a private-named unstratified noSuchMethod trap.
>
> /be
>
> ----- Original Message -----
> From: "Andrea Giammarchi" <andrea.giammarchi at gmail.com>
> To: "Dmitry Soshnikov" <dmitry.soshnikov at gmail.com>
> Cc: "Brendan Eich" <brendan at mozilla.com>, "es-discuss" <
> es-discuss at mozilla.org>
> Sent: Friday, December 16, 2011 8:30:47 AM
> Subject: Re: noSuchMethod: "funargs" + "invoke-only-phantoms"
>
> 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/20111217/0ec00cd6/attachment-0001.html>


More information about the es-discuss mailing list