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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
