Proxies: get+fn vs. invoke

Tom Van Cutsem tomvc.be at gmail.com
Wed Oct 27 09:07:37 PDT 2010


>
> But having now written some proxy code, I'm much less concerned about the
>> overhead of making a coherent proxy that has methods you can extract. That
>> leaves me thinking the case of "just give me the method_missing trap"
>> use-case is not worth the added weight. And Tom and Mark agree, and they are
>> the champions of this proposal.
>>
>
>  That's a good summary.
>
>
> Yep, the summary is good, but as was mentioned -- if to forget about
> noSuchMethod and to move it to the minor goal, then the major one -- is
> solving the issues related with current imitation of noSuchMethod (via
> get+fn). The most inconvenient issue, is that in this implementation always
> a function is returned (that breaks checks such as if (!foo.bar) foo.bar =
> {} -- and actually breaks principles of an abstraction -- a designer of the
> `foo` forces a user of the `foo` to have a very strange situation -- always
> a function is returned for every non-existing stuff; thus, the user, by
> principle of the abstraction shouldn't know that he deals with a proxied
> object). Unfortunately, this issue is unresolvable, since to have virtual
> functional objects (being able to pass them as funargs e.g.) it's required
> to return always a function for every non-existing property. Plus,
> inconvinience with caching/invalidationg the cache to keep the ===
> invariant.
>
> So, from this viewpoint, this additional noSuchMethod hook seems just a
> logical _consequence_ of trying to avoid these issues (but not a desire to
> exactly have it).
>

With the risk of going round the block again... ;-)

I agree with your premises, namely that:
a) `if (!foo.bar) foo.bar = {}` is a common pattern to patch up objects that
don't know how to deal with `bar` requests
b) a proxy that pretends to have all possible properties can't be patched up
using this pattern

But I don't buy your conclusion, which is that a + b implies that proxies
are somehow broken. If the proxy says "I know how to handle `bar`
properties", then the client doesn't need to patch up the proxy by adding a
`bar` property. Your patch-up pattern will work perfectly fine with proxies
that don't pretend to have a `foo` property.

There are good reasons for why proxy writers may want to distinguish get
from invoke (for example, because invoke doesn't require caching the
function returned by `get`), but IMHO this patch-up pattern is not one of
them.

>
>
>>  So can we let this stand for now and see how deployed Proxies in Firefox
>> 4, beat on by real users who are willing to try them as spec'ed without
>> noSuchMethod, fly with developers? That is one pretty good (albeit slow) way
>> to get new data and insights.
>>
>
>  I think this is a good choice in going forward. Since noSuchMethod can be
> an optional trap, it could be added later without breaking existing handlers
> that do not define it. The only issue we can run into is that some handler
> code out there already defines a noSuchMethod trap and means it to do
> something completely different than what a future spec. has in mind.
>
>
> Yes, possibly it's a good choice, it really seems just a design decision
> ("either with, or without it"). So a real users feedback will be possibly a
> better reason. Let it be. The only thing I'm also worried is that it
> won't become too late.
>
> P.S.: for fairness, possibly it's needed to mention on strawman proxy page,
> that such provided imitation of noSuchMethod has know lacks and that users
> should use it carefully.
>

I added a link to this conversation at
http://wiki.ecmascript.org/doku.php?id=harmony:proxies#simulating_nosuchmethod_doesnotunderstand

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101027/cbe88fe9/attachment-0001.html>


More information about the es-discuss mailing list