Proxies: get+fn vs. invoke

Dmitry A. Soshnikov dmitry.soshnikov at
Wed Oct 27 05:46:12 PDT 2010

On 26.10.2010 11:41, Tom Van Cutsem wrote:
> 2010/10/25 Brendan Eich <brendan at <mailto:brendan at>>
>     On Oct 25, 2010, at 12:35 PM, Tom Van Cutsem wrote:
>>     2010/10/20 Dmitry A. Soshnikov <dmitry.soshnikov at
>>     <mailto:dmitry.soshnikov at>>
>>         Anyway, is there an alternative how [[HasProperty]] can work
>>         correctly? I just though, that it's called by the "has" hook
>>         of a handler, which in turn can "lie" of course (i.e. return
>>         true when a property does not exist -- in such a case,
>>         noSuchMethod won't be called).
>>     I think Dmitry is right: calling [[HasProperty]] on a proxy
>>     object should trigger its "has()" trap in the normal way, which
>>     should work with double lifting.
>     IIRC the problem is a meta level-shifter wants to implement just
>     one trap, get in the absence of invoke. Would integration of
>     noSuchMethod using has ("object detection") break this?
> No, this would be the case if [[HasProperty]] were called directly on 
> the handler object. However, calling [[HasProperty]] on the proxy 
> object will still query the handler for its "has" trap using the 
> handler's [[Get]] internal method, i.e. it won't feature-test the 
> handler object directly.
>     Anyway, the general issue before us is a least this choice:
>     * Either we stick with the current more minimal design, which
>     besides being smaller also serves the goal of avoiding a
>     method_missing (honey-)trap that tends to break JS's
>     functional-programming,
>     methods-can-be-extracted-and-passed-around-as-funargs-for-later-apply-usage,
>     design win.
>     * Or we add noSuchMethod and satisfy the "just give me a new trap,
>     I'll either use it well in method-only programs or make it work
>     with has/get/etc." use-cases of Dmitry and others.
>     To reiterate something lest people get angry, this is not an easy
>     trade, and I don't see anyone being rigid. It's simply a design
>     decision we have to make one way or another.
>     Going into the process in TC39, as I noted previously, I did my
>     best to argue for noSuchMethod.

Damn, where have I been at that moment? ;)

>     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 (! = {} -- 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).

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


> Cheers,
> Tom
>     Or we could keep arguing here, but I think we've gone around the
>     same block more than once!
>     /be
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at <mailto:es-discuss at>
> _______________________________________________
> es-discuss mailing list
> es-discuss at

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

More information about the es-discuss mailing list