From: Austin Ziegler <halostatue@...>
Date: 2007-10-08T00:42:41+09:00
Subject: Re: The Case for Multiple-Inheritance

On 10/6/07, Trans <transfire@gmail.com> wrote:
> The thing is (and maybe this will help clarify how I see this) the
> more I work with Ruby the more I feel like the best code is always of
> the form:
>
>   module M; end
>   module X; end
>   module Y; end
>
>   class Z
>     extend M
>     include X
>     include Y
>   end
>
> Such that everything is a module and classes are always just
> compositions of modules. This provides maximum code reusability.

No, actually, it doesn't provide maximum code reusability. Ruby supports
a rich vocabulary and you're choosing to use a form that, while clearly
useful in some cases, is not right.

Modules in Ruby are useful for adding new "generic" class capabilities.

Enumerable is a way of using the ability to iterate over a collection
object (and a collection is defined by #each, which goes through the
*state values* of the object in turn). It's like a Java interface except
that you don't need to reimplement each and every piece of the interface
because the interface is always expressed in terms of #each.

Transaction::Simple is a way of adding "extra" state to an object that
allows it to be versioned in memory. All of that extra state is managed
by the methods defined in the module.

What you're talking about is on par with components and graphical
development. They can work in simple cases, but the moment you start
having complex cases, you start realizing that the code is becoming a
bit more complex to integrate that way. You can either refactor your
code, or start looking at ways that the language can change to
accomodate your model's inflexibility.

Modules aren't really meant for providing state that the object depends
on normally. They're *extra*. So you should be working with classes that
have implementations; you should refactor out common functionality (and
I mean REALLY common functionality) into modules; you should have a
class hierarchy if it's appropriate; you should compose multiple objects
into a single object where appropriate.

I'll put it clearly: if I were running a Ruby consultancy and a
programmer of mine used your methodology for everything (e.g., classes
defined by composing modules), I would not keep that programmer on. It's
a bad style. Sorry.

There are legitimate arguments (made by matju) for the unification of
class and module; your case is not one of them.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca