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

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Nov 12 14:17:39 PST 2012


On Nov 12, 2012, at 1:59 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> On Nov 12, 2012, at 1:20 PM, Brendan Eich wrote:
>> 
>>> Tom Van Cutsem wrote:
>>>>    Another potential consistency issue is between [[HasOwnProperty]]
>>>>    and [[GetOwnProperty]].  That could be eliminated by combining
>>>>    them into one operation:
>>>> 
>>>>    [[GetOwnPropety]](name, descriptorNeeded) ->  descriptor | boolean
>>>>    | undefined
>>>> 
>>>>    If descriptorNeeded is true it acts as the current
>>>>    [[GetOwnProperty]]. If descriptorNeeded is false it acts as the
>>>>    current [[HasOwnProperty]].
>>>> 
>>>>    At the handler-level it makes it impossible to override
>>>>    "hasOwn"without also overriding "getOwnPropertyDescriptor"
>>>> 
>>>> 
>>>> I understand the goals, but I'm not a big fan of fusing traps like this. It trades complexity on one level (inconsistencies between traps) for complexity on another level (if-tests in fused trap bodies to determine what type of value to return).
>>> Agreed. That kind of return value overloading has a smell.
>> 
>> Yes it does!  But allowing separate inconsistent implementations of [[HasOwnProperty]] and [[GetOwnProperty]]  enables the creation a big mess that may spell even worse.
> 
> Spelling aside, it smells better to me.
> 
>> Particularly, in this case where [[HasOwnProperty]] adds nothing essential as [[HasOwnProperty]] should always be equivalent the ToBoolean of the result of [[GetOwnProperty]].  It is really just an optimization to avoid reifying a descriptor in cases where it isn't needed.   From that perspective, a parameter that advises whether or a descriptor is needed does seem too smelly.
> 
> "does not"?

right "does not"

> 
>>    In C++ this might be expressed as two overloads for GetOwnProperty:
>> 
>> PropertyDescriptor*  HasOwnProperty(name k) {...}
>> 
>> bool HasOwnProperty(name k, bool needDescriptor) (...)
> 
> Sorry, this is JS not C++ and even in C++ flag parameters are considered a smell in many style guides.

As I covered, this is really all about optimizing away the need to reify a descriptor.  Often smelling things are done in the name of optimization.
> 
> We now have over two years experience with derived and fundamental traps in Firefox's proxy implementation, and the hazard of inconsistent traps is minor from what I can see. Cc'ing jorendorff for his view.

How many users of what skill levels and how much of that code has been fully debugged and put into production use.  How much of it has been with direct proxies  (the issues arise because for forwarding to the target)?  It isn't clear to me how much feedback we have on the current direct proxy API, particularly in regard to potential footguns.

Allen




More information about the es-discuss mailing list