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

Tom Van Cutsem at
Wed Sep 25 01:26:19 PDT 2013

I recall that Allen and I had previously agreed that it would be cleanest
if each of the [[internal]] methods on Object would correspond 1-to-1 to a
trap in the Proxy API (and I believe this is the case for the current ES6

So my stance is that we should either remove both hasOwn() and
[[HasOwnProperty]], or else remove neither.

I'm fine either way, but I believe Jason is right that [[HasOwnProperty]]
can be refactored as an abstract operation without any perf implications on
non-proxy objects.

2013/9/24 Jason Orendorff <jason.orendorff at>

> 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]].
> -j
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list