Catch-all proposal based on proxies

Mark S. Miller erights at
Fri Dec 11 18:30:35 PST 2009

On Fri, Dec 11, 2009 at 9:31 AM, Brendan Eich <brendan at> wrote:

> On Dec 11, 2009, at 8:36 AM, Maciej Stachowiak wrote:
>  On Dec 10, 2009, at 10:06 PM, Mark S. Miller wrote:
>>  has 263. I will proceed to worry only about hasOwnProperty until someone
>>> objects.
>> Note that these are hits found in source repositories, not on the Web. So
>> I would not put too much stock in the number of hits except as an existence
>> proof. Both of these include hits from JavaScript libraries, likely meaning
>> there are many deployed copies of the code in question (though unclear if
>> that code path gets hit as the JS libraries are used in practice).
> Absolutely. The best case with codesearch would be to get no results --
> that would suggest but not prove that the construct is not used. Getting any
> hits casts doubt on claim that the construct isn't used enough to worry
> about. More than a few handfuls of hits -> you should worry.
> Mark, I don't think we can pick meta-level methods to worry about and not
> worry about, if the goal is transparent wrapping or catch-all based DOM
> emulations. OTOH, propertyIsEnumerable is much less used than
> hasOwnProperty, whether directly or via .call. But in principle it is the
> same kind of animal.
I have now changed the spec so that
and Object.prototype. are base level rather than
meta level methods. Proxies can now virtualize them fine, at the price of
loading down the handler protocol with two more methods. As discussed
earlier, I also added an invoke: trap so that named method invocations can
be handled in one step without having to curry over the method name. So,
altogether, three more methods. On the other hand, the double reflection
needed by the membrane became simpler and faster, since the choke point is
now an invoke trap.

Of legacy methods, the only one which is still meta-level
is, as is necessary to preserve its meaning.
The similar remains in limbo awaiting a
clearer spec. Neither of these should impede faithful emulation of existing
DOM expectations.

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

More information about the es-discuss mailing list