Removing Proxy hasOwn() trap (Was: [[Invoke]] and implicit method calls)
allen at wirfs-brock.com
Tue Sep 24 09:10:49 PDT 2013
On Sep 24, 2013, at 8:13 AM, Jason Orendorff wrote:
> On Tue, Sep 24, 2013 at 7:23 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> [forking from [[invoke]]-thread for clarity]
>> Allen: would the removal of the hasOwn() trap imply that we can drop the
>> [[HasOwnProperty]] internal method altogether?
I look at the the opposite way -- we have an 'hasOwn' trap because be have a [[HasOwnProperty]] internal method ;-)
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.
> I searched the spec. There are not very many places where
> [[HasOwnProperty]] is used; each one can be replaced with a call to an
> Abstract Operation defined like this:
Right, an none of the places seem particularly performance sensitive. In particular, ordinary property lookup uses [[GetOwnProperty]] rather than [[HasOwnProperlty]]
> ----begin spec text----
> When the abstract operation HasOwnProperty is called with Object O and
> property key P, the following steps are taken:
> 1. Let desc be the result of calling the [[GetOwnProperty]] internal
> method of O with argument P.
> 2. ReturnIfAbrupt(desc).
> 3. If desc is undefined, then return false.
> 4. Return true.
> ----end spec text----
> This allows five or six sections defining [[HasOwnProperty]]
> implementations to be deleted. It's a nice simplification.
Yes, I'm a big fan of minimizing the number of MOP functions. However, I'm a bit uneasy that I can't recall specifically why it is still there. I'm pretty sure we've discussed this before.
More information about the es-discuss