On Monday, September 30, 2002, at 08:42 PM, Bryan Murphy wrote:

> Chris Gehlker wrote:
>
>>> While I understand your point, I do have to disagree and say that 
>>> Mixins aren't anything like interfaces coming from my perspective.
>>> From my perspective, interfaces and/or contracts are a way to 
>>> unerringly guarantee than an object *ALWAYS* provides specific 
>>> functionality.
>>
>>
>> You lost me there, Bryan, perhaps because the only languages that 
>> I've used interface inheritance in are Java and ObjC and Ruby. But in 
>> Java, anyway, when I say "implements xyz" I'm free to define xyz any 
>> way I want as log as the method takes standard arguments. In fact the 
>> message name is really no more than a hint as to what the method 
>> does. How can that be a 'contract'?
>>
> You're taking me way too literally.  Had I dwelled in horrendous 
> detail over every little word in my original post I would have been a 
> bit more carefull about my use of Interfaces and Contracts as they are 
> not the same thing (though they share similar features).  My main 
> point is simply that people want an easy and convenient way to 
> guarantee that things behave a certain way in Ruby.   Interfaces, 
> contracts, static typing, they are all attempts to do this that solve 
> different parts of the problem but don't solve the problem as a whole.
>
>

OK, I plead guilty. I've noticed that *some* people want "an easy and 
convenient way to guarantee that things behave a certain way in Ruby" 
but I'm still wrestling with:

1) Why do they want that
and
2) What does "behave a certain way" mean?

Though those questions aren't as distinct for me as the above dichotomy 
implies. If I use the same method name in two different classes, I seem 
to be expressing the idea that they are the 'same behavior' at some 
level of abstraction but obviously they are different at some level or 
detail. Even in C, adding ints is not really the same thing as adding 
floats.