On Fri, Dec 11, 2009 at 9:31 AM, Brendan Eich <[email protected]> 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 Object.prototype.hasOwnProperty.call and Object.prototype. propertyIsEnumerable.call 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 Object.prototype.toString.call, as is necessary to preserve its meaning. The similar Function.prototype.toString.call remains in limbo awaiting a clearer spec. Neither of these should impede faithful emulation of existing DOM expectations. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
