Proxies: get+fn vs. invoke

Tom Van Cutsem at
Wed Oct 13 12:33:47 PDT 2010

> 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`).

Apologies for the bad formatting. I blame my gmail editor ;)

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.

Hold on, the fact that a property is accessed either as `o.n` or `o.n(...)`
has nothing to do with `noSuchMethod`. Isn't "noSuchMethod" related to
whether or not `n` exists in a proxied object? Anyway, it does not make
sense for proxies since a proxy is an empty object and as far as the proxy
is concerned, all of the properties that it traps are in a sense "missing".

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).

I don't fully understand. Why should funargs/apply invariants be maintained
for real functions only?

The === invariant is indeed broken, but in the case of an invocation (as in
`o.n(...)`) it shouldn't matter, since the function returned by `o.n` is
immediately applied anyway and is not made visible to the caller.

> 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.

I cannot assess the impact of this change on JavaScriptCore so I won't make
any statements about that. In any case, a noSuchMethod/methodMissing hook
does not make sense on proxies since proxies can be used even when there is
no target object from which a method could be missing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list