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

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

> Allen Wirfs-Brock <allen at wirfs-brock.com> 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 wirfs-brock.com> 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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130925/bb204ee9/attachment.html>

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

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.