Proxies: get+fn vs. invoke

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Wed Oct 13 06:56:19 PDT 2010


  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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101013/1a61f6fc/attachment.html>


More information about the es-discuss mailing list