From: Jacob Fugal <lukfugl@...>
Date: 2006-02-09T05:24:54+09:00
Subject: Re: mixing in modules ?

On 2/8/06, konsu <konsu@hotmail.com> wrote:
> is it a bad programming style in ruby to use 'super' in a module definition?

I don't think so. I myself haven't yet run into the need to call super
in a module method, but I don't see why you shouldn't be able to, as
long as you make that expectation clear in the documentation for
anyone that might try and mix it in.

> that is, is it bad to invoke methods that will be defined in the object that
> will mix in this module?

Definitely not. The implementation of the methods provided by
enumerable are based on the assumption that the class that is mixing
in Enumerable will provide a few bootstrap methods, such as each. If
you try and mix in Enumerable without defining each, things just won't
work. The important thing is that this dependency/expectation is
provided up front in the documentation.

Regarding your original question on using @instance_vars in module
methods, I skipped over it at first since I wasn't fully sure about
which part of your question was about modules in general and which was
about eval'ing code from the DB. I'll try to answer the general
portion now...

There is nothing wrong with using @instance_vars in module methods
that are intended to be mixed in. You need to be careful though. I
consider two types of instance vars that a module method might use:

  * variables used exclusively by the module
  * variables the module expects the class to provide

In the first case, the module is keeping its own state for its
operations. The class that's mixing in the module should not care
about these instance variables and should leave them alone. As such,
you need to be very careful that you don't stomp on any of the class'
instance variables, and that it won't stomp on yours. This requires
very careful naming.

In the second case, I'd consider refactoring the module method to use
accessor methods on the class and thus abstract away the
implementation. This makes it easier to then adapt other classes which
may have different implementations to use the same mixin. Then, of
course, document the required *interface* (as opposed to required
instance variables) as mentioned above.

Jacob Fugal