2012/11/12 Allen Wirfs-Brock <al...@wirfs-brock.com> > > On Nov 12, 2012, at 2:21 AM, Brandon Benvie wrote: > > > Shouldn't it be the reverse, based on the removal of > getPropertyDescriptor/Names? The proxy controls what i's [[Prototype]] is > which indirectly directs how non-own lookups proceed. The functionality of > `has` can (and usually should) be derived from proto-walking hasOwn until > true or null. > > yes, that would be a good fix for this particular problem. > [[HasOwnProperty]] could remain as an internal method and HasProperty > could be defined as an abstraction operation that uses the [[Prototype]] > internal accessor and [[HasOwnProperty]]. >
I also like it. So this implies that we keep "hasOwn", get rid of the "has" trap, and that |name in proxy| triggers the proxy's hasOwn() trap. If that trap returns false, the proxy's |getPrototypeOf| trap is called and the search continues. > 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). Maybe I just need to get used to the fused trap signatures. I'll try to experiment by writing some code using such an API. Cheers, Tom
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
