Digging Deep: Mixing it up (or in) with Modules

by Gregory Brown

Yet another series attempt

I think my NubyGems series has gone over pretty well, so I figured I'd try my luck with something else.

This new series, digging deep, will be targeted towards the more experienced developer, or at least folks who want to know a little more about some deeper concepts in Ruby. I'm going to do what I can to make these as clear as possible, but I'm relying on input from gurus and skeptics to help improve these posts and make them a good resource for folks.

So this post will focus on a recent topic on RubyTalk, the merit of using Mixins as a suitable replacement for multiple inheritance.


Christoffer Sawicki
2007-01-20 05:08:48
@ruport_tags should probably point at a Set instead of at an Array.
2007-01-20 09:58:34

Ooh, wasn't banking on any Ruport feedback but you're absolutely right.


2007-01-21 11:43:23
hmm good one
2007-01-22 11:31:02
Modules are a great way to keep your code DRY too. Whenver I see repreated code in a script or application, I move it all into a module which I mix-in to whichever class needs it.

One pitfall of this approach is the modules tend to have strange names (because what they represent isn't totally clear yet), and some coupling to their original source classes (usually through expected instance variables or methods), but over time & refactoring those warts tend to smooth out.

2007-01-22 11:32:44

Yeah, names can be tricky. Usually Somethingable.
Remembering to pick an adjective usually helps, and you're right, over time things polish up.