I was looking at <http://www.juixe.com/techknow/index.php/2006/06/15/
mixins-in-ruby/> and it has a good discussion and explanation of
“include” versus “extend” for mixins of modules, which I find quite
informative. Bit off topic, but kinda related.
Hi, Thufir
I browsed the site, and I understand that it is very useful for
somebody coming from Java to begin to picture what ‘include/extend’ are
in Ruby.
However, beware that this kind of information is useful and ‘dangerous’
at the same time if taken literally; eg, the example it gives of a
Module hardcoding the class name (that is using it) is a bit… eery
(although I understand that he is just trying to show the mechanics of
interaction module-class).
In Ruby, a Module of course has no preconceived notion of the classes
using it; but, at the same time, if it needs to ‘talk’ to the class
using it, it can (see the humble Enumerable module; you write a class
including it, you define ‘each’, and suddenly… you get a bounty of
methods free; the module is in fact calling your ‘each’).
Not to mention Rails, were the interaction between Classes and Modules
becomes surreal (modules injecting code into classes at the moment that
those classes are being created…).
So, perhaps take that site with a grain of salt, and, when you have a
chance, try a good Ruby tutorial on Classes/Modules; a great thing in
Ruby is that one can read and test at the same time with irb even the
most complex inheritance scheme (so one does not get asleep in an ‘ocean
of abstractions’ :-).
using it, it can (see the humble Enumerable module; you write a class
including it, you define ‘each’, and suddenly… you get a bounty of
methods free; the module is in fact calling your ‘each’).
Thank you for the heads up, definitely something for me to come back to
Although I am a bit late into the discussion here are some points
where more discussion of topics like this can be found. This is really
about design patterns (as has been mentioned already).
A personal remark: sometimes I see it as a danger that delegation is
so easy in Ruby. The downside is that if you delegate all the
methods of a contained object you will completely clutter the outer
class’s interface and you overly increase the dependency between the
two. Sometimes this is just what you want (because for example you
hide the contained object completely from the outside) but at other
times you just create unnecessary complexity.
