On 11.10.2010 18:18, Tom Van Cutsem wrote:
In short: the 'get' trap can't distinguish the above two cases. This
is a pity, and I agree it would be useful for 'get' to have that
information sometimes. There has previously been talk on this list of
parameterizing 'get' with an additional flag to detect get+call vs
invoke, but it turned out that not all implementations would be able
to support it:
<https://mail.mozilla.org/pipermail/es-discuss/2010-May/011062.html>
In retrospect it may not be so bad that this feature isn't supported.
I can imagine it could lead people to write code like:
get: function(receiver, name, args) {
// suppose that args === undefined implies that the property was
only queried, not invoked
if (args === undefined || args.length === 0) {
return 'a';
} else {
...
}
}
So that obj.name <http://obj.name> and obj.name <http://obj.name>()
would both return 'a'. This could lead to a lot of confusion, since
it's hard to quantify what "obj.name <http://obj.name>" denotes. If
it's supposed to be a method, then obj.name <http://obj.name> should
return a function. If it's supposed to be a getter, then obj.name
<http://obj.name>() should call the thing returned by the getter
(which, in this case, should raise a type error since strings are not
callable)
Sorry, this part of your reply was formatted with a small text -- the
same as quote of my letter, so I completely lost it and didn't see at
all. Just saw it now in es-archive (there is no font size formatting).
Actually, you answered in this replay on the question I was asking in
the next letters (including a parametrized `get`).
Regarding this example with undefined args: I think you agree that
correct check should test `arguments.length` to see whether `args` is
here. However, as I mentioned, it may be more convenient to separate in
own place, i.e. to the `noSuchMethod` hook of a proxy handler.
Also I think now, that what was named as pros, i.e. ability to have
funargs and call/apply invariants, in real, not so pros. Because users
more likely want to catch exactly missing methods (if you don't like the
word "methods", since there're no methods, there are properties, let's
say -- missing properties which ended with `call expression` at the
call-site). And funargs/apply invariants should be leaved for _real
functions_ (existing or ad-hoc, explicitly returned from the `get`).
Moreover, as it has been mentioned, such returning has broken ===
invariant anyway (and also broken invariant with non-existing properties).
So I still propose to include to proxy handlers either this
parametrized `get` with the third `args` parameter, or a separated
noSuchMethod/methodMissing hook, and do not bother about funargs/apply
scheme (because, by logic this scheme is even not so correct; again --
it should be leaved for _real_ functions of the `get`). I am sure,
JavaScriptCore can manage this case.
What do you think?
Dmitry.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
