Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

Tom Van Cutsem at
Wed Nov 14 00:33:53 PST 2012

2012/11/13 Erik Arvidsson <erik.arvidsson at>

> On Tue, Nov 13, 2012 at 3:25 PM, Tom Van Cutsem < at>wrote:
>> So, my proposal: let's revert the fundamental traps of Handler to become
>> abstract methods again. This forces subclasses of Handler to provide all
>> fundamentals at once, avoiding the footgun.
> Maybe we should skip the derived traps for ES6 and see if the extra
> allocation really becomes an issue in reality? This way we are keeping the
> API smaller and the risk of errors lower. We can always add the derived
> traps later, can't we?

I would subscribe to this point of view if only all derived traps were as
trivial to remove as the "has" or "hasOwn" traps that were brought up by
Allen in this thread.

Looking at the full list of fundamental vs derived traps <>, it
quickly becomes apparent that there are far more derived than fundamental
traps. It'll be a challenge to try and get rid of all derived traps.

Now scroll down to the "non-normative implementation" section of that wiki
page and have a look at the default implementation of "hasOwn". It's only 3
lines, making it by far the shortest derived trap. Many of the other ones
(e.g. keys() and enumerate()), perform spurious property descriptor
allocations in a for-loop, making the allocation overhead linear instead of

As Allen mentioned himself, the "hasOwn" trap was a good case to bootstrap
the discussion because of its simplicity: it's easy to understand the
inconsistencies, it's easy to get rid of, and the extra allocation cost is
minimal. The story is not so simple for the other derived traps.

All of this is just to adjust the bias that getting rid of all derived
traps would be an easy thing to do.

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

More information about the es-discuss mailing list