From: "David A. Black" <dblack@...>
Date: 2004-08-14T23:49:33+09:00
Subject: Re: Opinion on ClassInherit Include

Hi --

On Sat, 14 Aug 2004, T. Onoma wrote:

> On Saturday 14 August 2004 10:06 am, Robert Klemme wrote:
> > You didn't say so in your original post.  And as far as I can see you have
> > two modules in your example, too.  As you obviously noticed, you need to
> > identify those parts that should go into instances and those for the class
> > *somehow*.  So having two separate modules is really the simplest way.
> 
> Okay, more detail then. 
> 
> Currently I have a class that can be subclassed to inherit behavior, but I 
> want to turn that into a mixin module instead. Problem is that the class has 
> class methods that need to be inherited too. Can't do that with a module, so 
> I had to figure out a way. Of course I could use two *seperate* modules, as 
> you say, but then the lib user would have to add two lines of code (an 
> include and an extend) to get functionality that really belongs together.
> 
> So let me ask it this way: I have class behavior and instance behavior that 
> needs to encapsulated into a single mixin unit. How to do it?

There's no way to redefine Ruby's sense of a mixin, which happens one
transaction at a time.  But if you want to do it all in one command,
you could do:

  class Module
    def dual_mixin(mod)
      include mod
      extend mod::Inner
    end
  end

  module MyMod
    module Inner
      def x
	puts "hi"
      end
    end
    def y
      puts "hy"
    end
  end

  class C
    dual_mixin MyMod
  end

  C.x        # hi
  C.new.y    # hy

While this carries the usual dangers of adding on to base classes, I
think it's better than actually redefining an existing method of
Module.  It also draws attention to the fact that two transactions are
taking place, which in turn makes the subsequent code easier to
understand.


David

-- 
David A. Black
dblack@wobblini.net