Hi --

On Mon, 16 Oct 2006, Jeff Cohen wrote:

> Making my way through Ruby for Rails (excellent book, David), but am
> puzzled by the explanation of why Rails jumps through hoops to turn
> Module instance methods into class methods.
>
> On p. 463, David represents the situation sans Rails:
>
> module A
>  module M
>   module ClassMethods
>     def some_method
>       #...
>     end
>
>   def included(c)
>     c.extend(ClassMethods)
>   end
>  end
> end
>
> and then a class later that does this:
>
> class B
>  include A::M
> end
>
> The goal as for M::ClassMethods to become class methods of B.  Whew.
>
> Here are my questions:
>
> 1. Why can't class B just extend A::M::ClassMethods?  Why use include
> and therefore necessitate this whole indirect approach?  Must be some
> advantage that I'm not seeing?

The goal is to be able to do one "include" and have both instance
methods and class methods added to the class that's doing the
including.

> In other words, why couldn't this have worked?
>
> class B
>  extend A::M::ClassMethods
> end
>
> and then there's no need M::included() needed at all?

You'd have to do:

   class B
     include A::M
     extend A::M::ClassMethods
   end

to get the same effect.

> 2. I guess because M::included() was overridden, class B did not get any
> instance methods - which I think would have normally been the case with
> an include statement.  SO what if you wanted the "normal" inclusion
> behavior, but also wanted to do something "extra" when your module is
> included?

You still get the normal behavior -- that is, class B will still mix
in any instance methods defined in A::M.


David

-- 
                   David A. Black | dblack / wobblini.net
Author of "Ruby for Rails"   [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog)        [2] | Co-director, Ruby Central, Inc.   [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com    | [4] http://www.rubycentral.org