From: Phil Tomson <rubyfan@...>
Date: 2006-06-09T15:52:54+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?

On 6/8/06, Austin Ziegler <halostatue@gmail.com> wrote:
> On 6/8/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> > On Fri, 9 Jun 2006, Yukihiro Matsumoto wrote:
> > > I don't like the name #inherit.  Since it is not a inheritance.
> > i've suggested 'mixin' in the past
> >
> >    module M
> >    end
> >
> >    class C
> >      mixin M
> >    end
>
> Um. I think that's too confusing. The problem is that we want to be clear that:
>
>   * #include only deals with the inclusion of instance-level methods
> at the instance level.
>   * #extend only deals with inclusion of instance-level methods at the
> class/object level.
>   * #??? includes both instance- and class-level methods at the
> instance/class level.
>
> In my mind, #mixin does not capture that, since the process of
> #include *or* #extend is called mixing-in.
>
> No, I don't have a better name. I thought of #blend, but that's just
> too ... ugly.
>


What about a this approach:

module A
  def A.foo
    "this method wouldn't get mixed in"
  end
  def self.bar
    "this method would get mixed in"
  end
end

class B
  include A
end

B.bar #=> "this method would get mixed in"
B.foo #=> no method error

So the idea would be that if you use 'def self.<method_name>'  the
method would be mixed in, but if you use 'def <module name>.<method
name>' it would not be mixed in.


...I'm not sure how easy/hard/possible this would be to implement,
though, or if it's even practical.

Another approach would be to so something like:

module A
  def self.not_mixable
    "not mixed in"
  end

  mixable
  def self.mixed
    "mixed in"
   end
end

class B
  include A
end

B.mixed #=> "mixed in"
B.not_mixable #=> no method error

Phil