[#1378] differences between Module and Class ? — Mathieu Bouchard <matju@...>

25 messages 2003/08/11
[#1387] Re: differences between Module and Class ? — matz@... (Yukihiro Matsumoto) 2003/08/12

Hi,

[#1442] Re: differences between Module and Class ? — Mathieu Bouchard <matju@...> 2003/08/21

[#1406] _id2ref bug? — Ryan Pavlik <rpav@...>

While debugging some caching code, I've come across a segfault related

22 messages 2003/08/14
[#1407] Re: _id2ref bug? — matz@... (Yukihiro Matsumoto) 2003/08/14

Hi,

[#1413] Re: _id2ref bug? (REPRODUCED, short) — Ryan Pavlik <rpav@...> 2003/08/14

On Fri, 15 Aug 2003 01:57:18 +0900

Re: differences between Module and Class ?

From: "Sean E. Russell" <ser@...>
Date: 2003-08-24 18:16:10 UTC
List: ruby-core #1473
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 24 August 2003 13:05, Mathieu Bouchard wrote:
> > inheritance can be "is-a" relation. This combination is indeed a
> > restricted multiple inheritance.  By this restriction, we won't have
> > diamond inheritance problem,
>
> module A; end
> module B; include A; end
> module C; include A; end
> class D; include C,B; end
>
> This is a diamond inheritance pattern.

I know that this is just a semantic difference, and lord knows I'm not John 
McCarthy, but I've always found the separation and difference between mixins 
and inheritance in Ruby to be intuitive and clear.

When I think of Ruby mixins, I think of adding methods to an object (or class) 
- -- a function-oriented procedure.  In Ruby, commonly, these mixins aren't 
object oriented -- that is, they don't generally operate on the object 
they're attached to.  They don't affect the state of an object, and they 
don't make any assumptions about the object context.(1).  For example, the 
Enumerable module is a namespace for methods which assume nothing more than 
the presence of some #each method (and, optionally #min and #max) also being 
defined in the same name space at execution time.

Inheritance is, in my mind, a different beast altogether.  OO inheritance 
implies state and context.  Inherited methods are *expected* to modify the 
state of the object, or report on the state of the object based on some 
intimate knowledge of the object.   If they don't, good OO design suggests 
that they probably shouldn't be object methods in the first place.

So, IMO, there is a very clear difference between multiple inheritance and 
multiple mixins from modules.  Matz originally characterized inheritance as 
"is-a" and mixins as "has-a", although he retracted that.  Both of these are 
noun-oriented designations.  I'd say a more useful way of looking at Ruby 
mixins is "can".   Mixins are verbs; inheritance is nouns.

I'm sorry if I'm not being clear, and I'm not particularly interested in 
getting involved in an argument over what "is-a" or "has-a" means, or whether 
it applies to method signatures.  I'm merely saying that Ruby's distinction 
between mixins and inheritance makes a lot of sense to me.


(1) Ruby mixins *can* modify the state of an object, but most of the core Ruby 
modules don't.   Therefore, I speak not of what Ruby "can do", but what Ruby 
"does", in a "best practices" sort of way.

- -- 
### SER   
### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido|Dirigibles
### http://www.germane-software.com/~ser  jabber.com:ser  ICQ:83578737 
### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/SQDJP0KxygnleI8RAvt/AJ9TOaiO2CaFy2LczJ0YrUUTQ7yipACcCIO2
xjmxmBg47g3UijeRqRVhcAc=
=O7tk
-----END PGP SIGNATURE-----



In This Thread