Jano Svitok
10/16/2006 8:41:00 AM
On 10/16/06, Jeff Cohen <cohen.jeff@gmail.com> 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?
>
> 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?
>
> 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?
>
> Thanks!
> Jeff
1. The reason in unification - you don't need to remember where to use
include and where extend, and this way you get both instance and class
methods.
2. overriding include should have no impact on actual method
including. It's just a callback. All the stuff is being done in
append_features. (At least that's what documentation says.)
So either the docs are wrong, or your problem is somewhere else.