Gavin Sinclair wrote:

>Ruby's mixins have similar features to Java interfaces, but they are more
>flexible, and don't play any specification role.  Also, Ruby classes don't need
>any interface description to be able to plug-n-play; they just need to support
>the rigth methods at the right time.
>
>In short, it's not a technical reason.  Ruby doesn't want to be as strict as
>Java.  Result: more flexibility, but no guarantees.
>
>If you find yourself in a situation where you want these things, but also want
>to use Ruby, either:
> - use Ruby as a prototype and then convert to Java if necessary
> - enforce type-compliance to key methods by raising exceptions
>  
>
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.  Mixins are a way to share common functionality amongst 
multiple objects via code-reuse, but they don't guarantee that said 
functionality will be implemented (methods can be changed after the 
fact).  A contract says I must do something.  If I no longer do 
something, I no longer follow that contract and it is therefore no 
longer valid.  I've never read anything about Ruby Mixins being 
immutible like this

Also, another important reason why I think the two concepts don't serve 
the same purpose is that interfaces *only* guarantee functionality. 
 They say nothing about how that functionality is implemented (are you 
reading from a database? or from an xml file?).  A mixin is a mixin and 
it behaves a certain way.  You can have two mixins with the same 
behavior, they may look and act the same but they are in fact two 
distinct things (unless I'm misunderstanding Mixins).

You can use Mixins to implement interface like funtionality, so your 
point is certainly valid.  But you can't use Mixins to GUARANTEE that 
functionality across the board for all time.  That's the missing piece 
for a lot of us.

Bryan