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.

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

Reply via email to