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

David Bruant bruant.d at
Tue Nov 13 12:39:30 PST 2012

Le 13/11/2012 19:28, Allen Wirfs-Brock a écrit :
> On Nov 13, 2012, at 1:44 AM, David Bruant wrote:
>> I'm fine if we're discussing removing some other inconsistencies, but I'd be more interested in seeing a principled way to decide which inconsistency we're getting rid of and which we still allow. In other word, what makes an given inconsistency a bad thing?
>> The previous answer we had was in essence "if it prevents defensive programming" (Tom or Mark will correct me if I'm misinterpreting or miswording it) and with the current proxy design, it's possible to offer freedom to proxies as long as it's within the boundaries of respecting non-configurable properties and non-extensible invariants.
>> What would be the new answer to my question?
> footgun-ness
> I totally agree with you.  The possibility of inconsistency is inherent in this style of metaprogramming.  There is no way we can practically prevent somebody from coding a proxy  handler that intentionally produces inconsistent results.  The lowest layers of the specification/implementations must robust in the presence of such inconsistencies.
> But we should also try to avoid making it too easy for developers to unintentionally create such inconsistencies. Proxies have a API model that (intentionally) permits handlers that only  implement of a subset of the traps.   This is good, up to a point but if the traps don't have orthogonal functionality it becomes easy to unintentionally introduce inconsistencies simply by leaving out  a handler method.  We can engineer the API to reduce the occurrence of unintended inconsistency.   One thing we can do is minimize redundant traps that are expected to produce consistent results.  We may also fine it use for to merge traps in ways that centralize such semantics in one place.  We can eliminate traps (eg [[Iterate]] by promoting the functionality out of the meta layer.  Overall, the surface area of the MOP should probably be as small as possible.
> We've explored the security issues or proxies in depth.  Now is the time to explore the usability issues.
Very good point.

>    Proxies are not intended for novices but there still will be thousands of developers trying to use proxies who are neither metaprogramming experts or  have a deep understand of the ES MOP.  We should try to minimize the number of footguns and other hazards that they have to face.
Ok, this rationale sounds good to me. My original impression was that 
this thread was taking one inconsistency out of the blue, but I'm 
completely fine with what you just stated.


More information about the es-discuss mailing list