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"?

    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.

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.

/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to