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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
