Removing Proxy hasOwn() trap (Was: [[Invoke]] and implicit method calls)

Jason Orendorff jason.orendorff at
Tue Sep 24 13:46:05 PDT 2013

Allen Wirfs-Brock <allen at> wrote:
> On Sep 24, 2013, at 12:15 PM, André Bargull wrote:
>> On Tue, Sep 24, 2013 at 2:34 PM, Allen Wirfs-Brock <allen at> wrote:
>>> I pretty sure we discussed this before and decided we wanted to
>>> keep [[HasOwnProperty]]. However, the only reason I can think of
>>> for doing so now is to avoid forcing exotic objects to allocated the
>>> property descriptors that [[GetOwnProperty]] produces.
>> Exotic string and integer indexed objects ( = TypedArray instances) provide
>> custom implementations for [[HasOwnProperty]] for exactly this reason.
> And because of proxies, a specified call  to  [[GetOwnProperty]] can't be
> optimized away unless you're sure you are dealing with an ordinary object.

Here are three ways implementations can avoid this allocation.

1. We are usually sure we’re dealing with an ordinary object! The only
performance-sensitive call site is in [[HasProperty]] for ordinary
objects, and there it is of course given that O is ordinary. An
implementation can easily avoid the allocation in this case.

2. In *all* HasOwnProperty call sites, the object will normally be
ordinary. Implementations can optimize for that case using the same
techniques they already use for everything else in the language.

3. An implementation can certainly have an Object::hasOwnProperty
virtual method, if it’s faster, even if the spec calls it an abstract
operation rather than an internal method. Proxy::hasOwnProperty would
have to call the getOwnPropertyDescriptor trap; all other
implementations could avoid the allocation.

I hope my point here is clear. There’s no performance reason to retain
the .hasOwn trap or [[HasOwnProperty]].


More information about the es-discuss mailing list