Static versus dynamic binding of in contracts again - trying to set things straight

[Stewart Gordon]

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.