On 09/05/2012 11:55, Regan Heath wrote:
Reading that summary, and deadalnix's further comment I am inclined to agree
that
contracts should be (a) static.
It also made me think.. are we defining in/out contracts in the wrong place? or
in the
wrong way? What if we defined them on interfaces instead of classes?
We should be able to define contracts on interface methods, abstract class methods and
normal class methods on an equal footing.
http://d.puremagic.com/issues/show_bug.cgi?id=6549
<snip>
Perhaps we could have both static and dynamic contracts? Contracts defined on
classes (not
interfaces) could remain dynamic as they are currently, but contracts defined on
interfaces could be static. Giving us the best of both worlds.
I'm not sure what the point of this would be. What is the best of the dynamic
contract world?
Moreover, classes define an API in the same way as interfaces do. Violating a contract on
a class method is violating the API in the same way as it is for interfaces. It would be
arbitrary and confusing to have this conjured-up difference between classes and interfaces.
Stewart.
