[ruby-talk:8801] Re: Modules and mixins

On  7 Jan, Holden Glova wrote:
> Hello all,

Hello you, :-)

(...)

> I have never had an exposure to anything like mixins throughout my
> degree and sadly am feeling quite lost, which I'm sure will pass with
> time and hopefully the patience of the list as I ask silly questions
> about this topic.

do not feel to sad! It is not such a big issue. What makes it a bit
difficult to explain, however, is that due to Ruby's flexibility and
power, the answer comes in three flavours, at least. You know, although
Ruby is a real and complete OOL, it let *you* decide to use which
paradigm to program in. It do not force you to use OOP at all.

The three paradigms, Ruby supports and I want to mention, are:

o Procedural programming
  In this paradigm you use classes as struct/record like datatype
  definition. Or you can use the class OpenStruct for this
  purpose instead.

  Modules, however, will be used to build ... ehrm ... just modules. ;-)
  Namespaces to group functions and data together. Much like in e.g.
  Modula 2, Oberon, Turbo Pascal's Units or even C++ namespaces. But
  modules, of course, can do much more ...

o OOP (Class based)
  Here modules have additional sense. You can use them like in the
  procedural programming, explained above, but you can use them also to
  group functionalities together. These functionalities have not
  necessarily anything to do with any certain class.

  A good example is e.g. the module Enumerable. This module contains
  many functionalities (coded using methods) that describe tasks that
  could be applied to any container/stream or whatever like instance
  that can iterate thru its contained objects via method 'each'.

  You could see a module as the brother at the other end of the spectrum
  of class based OOP. Classes describes objects and the methods that
  could be applied on them. Modules describe functionalities that could
  be applied to *any* object, iff certain preconditions (e.g. existence
  of certain method(s)) are met. Or using another POV: A class group
  data, making the internal state of an object and some code that could
  be applied on *that* set of data, whereas a module group tasks
  (code) together that seeming to belong into same family but not
  necessarily depending on an object's internal state.

  In languages like C++ or even Python, there is no such concept like
  Ruby's modules. Here you have to mis-use (IMHO, of course) classes to
  group only functionalities and use them via multiple inheritance. Not
  worth the trouble IMO, as *true* multiple inheritance (A is_a B and A
  is_a C) is really seldom necessary!

o Classless OO
  That paradigm is also called prototype based programming. Here you
  really didn't need classes to do anything in your program. While in
  'classic' OO, you need to create a class to describe the objects
  (means instances) you want to create, in classless OO you simply build
  concrete, ready-to-use objects with desired structure and behavior. If
  you need more then one instantiation of such an object, you simply
  clone an already existing one and have two of them then.

  In Ruby you can also use modules here to build the concrete objects of
  prototype based system. By doing this, modules will therefore not only
  contain similar functionalities, unlike in the class based OO, but
  also data to reflect internal state of that special object. A further
  usage of modules in Ruby ...

Of course, nobody will prevent you from mixing these all in your program
;-)

> What I really don't understand is when do I use a module? How do I
> know that I should have a class in this module that is to be
> "extended" from in it's useage. What heuristics do you folks use?
> What patterns do you follow that spark these design decisions?

Reading my sermon above, you possibly may get some hints for what
modules can be good for. Of course Ruby will not enforce you to chose
one way over another one for your programming. All is anytime available.
Use whatever you want to use. Ruby "(...)stays out of your way(...)" and
features all your ideas!

A further hint: please do not restrict yourself by using a classical
approach! Try to find out what meets your needs and decide *then*. I
have tried to show you only the beginning of the way, the rest you will
have to find out for yourself on your journey; and all the fun is on
that journey, indeed :-)))

Perhaps tell us later, what you have found then, yes? :-)

> Thanks in advance for any contributions to this topic.

(...)

> Signed,
> Holden Glova


HTH,
\cle