On 17.12.2011 9:56, Andrea Giammarchi wrote:
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.
It was my main thoughts and arguments through that "never-ending initial
thread". And this position of course makes perfect sense.
However, it may also be broken until we don't have the answer to the
following question:
Why does a programmer have an error in the following transformation of a
code?
Was:
lib.toRussianName("Andrea"); // ??????
Became:
var toRussianName = lib.toRussianName;
toRussianName.apply(null, ["Andrea", "Alex"]); // error, "toRussianName"
is undefined
If you can explain it to the programmer that she should first go to the
documentation and to see that methods such as `to<Country>Name' are
virtual, but not real and then to use all such cases with caution, then
this is OK. This is actually the only way to solve this issue -- to tell
the programmer "go to the documentation and check which virtual, i.e.
invoke-only methods you have".
In other case, you can't explain to her why she, being in JS, can't
transform this line of a code into the second one. Can she do this? Does
she have rights/license for this? Of course she can, of course she does.
But in all other broken cases -- I already said, I agree that this
implementation also breaks some logic. And in the same manner you'll
have to explain to the programmer why if she:
delete lib.toRussianName;
then it still:
typeof lib.toRussianName; // "function", Trollface ;D
So, the only answer on this topic is should be the answer on "what is
less painful and less critical" in this case? To explain one broken
invariants or others? Once we have answered this question, we may easily
implement any from this design decisions.
Dmitry.
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 <[email protected]
<mailto:[email protected]>> 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" <[email protected]
<mailto:[email protected]>>
To: "Dmitry Soshnikov" <[email protected]
<mailto:[email protected]>>
Cc: "Brendan Eich" <[email protected]
<mailto:[email protected]>>, "es-discuss"
<[email protected] <mailto:[email protected]>>
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 <
[email protected] <mailto:[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] <mailto:[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]
<mailto:[email protected]> >
To: "es-discuss" < [email protected]
<mailto:[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] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
