Proxies: get+fn vs. invoke

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Wed Oct 13 15:28:20 PDT 2010


  On 13.10.2010 23:33, Tom Van Cutsem wrote:
>
>     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?

Yes, I wonted to mention it too. What is proposed in the view of 
parametrized `get`, is `invoke` -- i.e. catch for all calls. It can be 
considered also (again, depending on a call-site context), however, the 
most interest consists in exactly _missing property_. And not _just_ a 
missing property, but the missing property with a call expression at a 
call-site. This is exactly (and correctly, and needed) how 
__noSuchMethod__ of SpiderMonkey works.

If a property exists, and we have a call expression call-site, 
noSuchMethod shouldn't be called. Since this is just a normal property, 
which can be, or can not be a function (in first case we have a function 
call, in the later -- a TypeError "not a function"). It can be a normal 
property, or an ad-hoc, specially returned by the `get` hook (and again, 
if the later, it can be a function or not). For this normally should 
work funargs/apply.

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

The main purpose of a proxy is to proxy an object. It doesn't matter 
whether it's empty or not. It have special hooks. One of such, 
additional, hook -- noSuchMethod, would be nice to have.

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

Because, repeat, more likely JS programmers like to have and ability to 
catch exactly _call expressions_ on non-existing properties. A 
non-existing method in this ideology shouldn't behave as a normal 
existing property (for this purpose, repeat, programmers have real 
existing or ad-hoc `get`'s methods). The presence of noSuchMethod with 
catching such methods does not assume that the method should somehow be 
alive. It's just a signal to do something else ("I cannot reply the 
message, do something!"), e.g. to change dispatching by alternative 
prototype chain (no matter). It's not required that this _non-existing_ 
method become existing.

And again, since === invariant is broken, funargs/applys also can be 
easily broken. It just seems that it's a great innovation to have an 
ability of funargs/apply, but repeat, most of programmers want first to 
catch exactly _call expressions_ on missing properties and then maybe 
(maybe!) such (sic!) broken anyway "invariants" (yeah, they are even not 
invariants, 'cause they are broken).

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

Besides === invariant, sorry for repeating again, the invariant with if 
(!o.n) {o.n = ...} is also broken. This is absolutely enough to cancel 
this implementation of noSuchMethod.

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

I too. How do you think, would it be good to ask Oliver Hunt this question?

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

Does not make sense in any case?

OK, let me understand your position first. Are you ideologically against 
this hook? Because analyzing the talk (and previous talks) I see that 
your position changes on some minor aspects -- first "it's a useful 
think, but, unfortunately, JavaScriptCore...", then "it does not make 
sense in any case" -- just as you would against even an idea of 
noSuchMethod.

I may ask any JS programmer does he need noSuchMethod and in which way? 
Brendan implemented it before (a native __noSuchMethod__), Brendan also 
was agree that this is an interesting idea (when the parametrized `get` 
was discussed first). I've heard from many other programmers, "why the 
heck, SpiderMonkey the only which supports __noSuchMethod__?" "It would 
be good to have __noSuchProperty__ also!" - they said.

And now I don't understand, why are you categorically against and say 
that there is no any sense? Because some steps later you analyzed it 
from the position that we can either imitate it with `get` of a proxy, 
or "JavaScriptCore has some issues with its VM". But unfortunately, (1) 
we _can't_ imitate it, because this implementation is _broken and wrong_ 
(despite that it looks brightly working and even with supporting 
funargs/apply "invariants" -- repeat, it _does not_ support them, 
because they are also broken because of === is broken). And also the 
main invariant with non-existing property is broken; (2) I really 
believe that JavaScriptCore devs can make everything possible and fix 
the VM as needed.

However, since this is a committee, I think the decision should be made 
by the committee and with a voting. With analyzing pros and cons. And 
_before_ that -- with analyzing of what JS programmers are _really_ want.

What is wrong if this hook will be added? You don't like it 
ideologically? -- No problem, just don't use it (don't defined on a 
handler), use your approach with `get` returning each time a new 
function. Get your broken tests with if (!o.n) {...}. Do not inherit 
from deeper object, just put your proxy which always returns a new 
function as a prototype. Get your funargs, apply them. Repeat it twice 
with saving previous funargs, test them for === on the next step. Nobody 
can prevent from this actions -- if user will won't, he will do it. But 
other users will be glad to use noSuchMethod hook on a proxy handler and 
catch missed properties with a call expression on the call-site. And 
this fact possibly won't be mean for them that this _missed_ property is 
some _alive function_, no they just want to handle the case, the don't 
need this alive function.

This is really an important question and I ask the committee to consider 
it. With the voting. It cannot be that the decision is just made, 
because someone personally just don't like it or there are some issues 
of an implementation.

Thanks,
Dmitry.

> Cheers,
> Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101014/f2d8c1c7/attachment-0001.html>


More information about the es-discuss mailing list