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

[Regan Heath]

On Wed, 09 May 2012 13:23:03 +0100, Stewart Gordon <smjg_1998 at yahoo.com>  
wrote:

> 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?

I've only read the summary, so... If there is no consensus then someone  
obviously sees some benefit to it.  Personally, as I said, I think  
"static" is the 'correct' way for contracts to work, but perhaps the  
reason why ppl like dynamic is that 'correct' is not always 'practical' or  
'useful'.  Having dynamic contracts allows sub-classes to alter them, that  
could be a benefit to some.  It doesn't seem 'correct' to me, violating  
the substitution principle and all, but I can see how it might be  
practical/useful.

> Moreover, classes define an API in the same way as interfaces do.

Yes, but an API is only one part or one form of contract.  in/out  
contracts provide additional limitations/guarantees, beyond what a  
"standard"(*) OOP API does.  For example, a "standard"(*) OOP API can only  
define the type of input, not the range of acceptable values.

(*) I'm saying "standard" here because I'm referring to the common usage  
of class, sub-class, interface without the addition of more complex  
template, static if, mixin, or other language features not common to the  
main OOP languages; C++, Java, C#, ..

> 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.

I agree, classes and interfaces define APIs.  But, an interface is  
generally thought of as a more formal API, somehow /more/ of a contract  
than whatever methods happen to exist in a class at a given time.  in/out  
are currently used as an additional contracts, and currently applied to  
class methods.  But, is that 'correct'?

It seemed to me it might be cleaner/clearer and more correct to require  
in/out to be applied only to interfaces, where there is no concrete  
implementation.  Having applied them to classes and moreover to specific  
implementations of methods in classes we've created the idea that they  
could be dynamic and I suspect the current dynamic implementation in DMD  
just followed naturally from that.

I agree, having different behaviour for interfaces/classes /might/ be  
confusing.. Then again, I would expect static behaviour from an in/out  
defined on an interface, and it seems that some people expect dynamic  
behaviour from in/out defined on classes so it's possible that it's just  
the behaviour people would expect.  In any case I only suggested it as a  
possible middle ground.

Personally I'd like to explore the idea that it might be less confusing  
and more correct to require the use of an interface to define in/out  
contracts.  Would that be too much of a burden?  Would it result in a huge  
number of "redundant" interfaces?  Or, would it force people to write more  
correct code?  I know I've see /a lot/ of code which would have been  
written better had someone had the forethought to design the  
interfaces/contracts first, and once they exist would have thought harder  
about changing them during initial development and beyond.

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/