From: "Sean E. Russell" Date: 2003-08-25T03:16:10+09:00 Subject: Re: differences between Module and Class ? -----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-----