> > 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. Cheers, Tom
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
