Sean
10/11/2006 7:18:00 PM
> > Is there a better way to do this?I don't think there's any way that doesn't involve some kind of
> coupling, since you're basically printing one module's constant from
> another module (using "module" as class-or-module). The way you've
> done it presupposes that ExtendMeSecond will indeed be mixed in to a
> singleton class subsequent to the mixing in of ExtendMeFirst. You
> could, instead, cut out one leg of the journey and just say:
>
> def print_bar
> puts ExtendMeFirst::BAR
> end
>
> which is a different kind of coupling, but really isn't inherently
> worse than calling Math::PI or any other constant from another module.
>
> David
This problem originally arose from trying to extend/alter some
functionality of Rails in a plugin, and needing access to some
constants defined in a ClassMethods module that uses the:
def self.append_features(base) # :nodoc:
super
base.extend ClassMethods
...
idiom that is used frequently in rails. To me, the "mixin" concept
creates some weird decisions to make with repsect to coupling. In some
other OOP languages, extending the functionality might be done by
creating a new class that derives from ActiveRecord, and then
overriding the functions in question to provide new behavior.
In Ruby/Rails however, especially with plugins, it seems to be much
more common to use the include and extend functionality to bring new
functions into an existing class, or override them. When you do this,
you're frequently going to want to make assumptions about your context
in the new mixin since you know where it's going, however, conceptually
a mixin should be somewhat context ignorant, should it not?