Proxies: get+fn vs. invoke

Tom Van Cutsem at
Tue Oct 26 00:41:43 PDT 2010

2010/10/25 Brendan Eich <brendan at>

> On Oct 25, 2010, at 12:35 PM, Tom Van Cutsem wrote:
> 2010/10/20 Dmitry A. Soshnikov <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. 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.

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


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list