# Module include class/instance methods confusion!

**URL:** <https://www.ruby-forum.com/t/module-include-class-instance-methods-confusion/160866>\
**Category:** Ruby\
**Created:** [February 20, 2009, 2:01pm UTC](https://www.ruby-forum.com/t/module-include-class-instance-methods-confusion/160866 "2009-02-20T14:01:04Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![hirodusk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/6f9a4e/32.png) [@hirodusk](https://www.ruby-forum.com/u/hirodusk)\
**Post date:** [February 20, 2009, 2:01pm UTC](https://www.ruby-forum.com/t/module-include-class-instance-methods-confusion/160866/1 "2009-02-20T14:01:04Z")

</div>

I have been having trouble today with a module include in a Rails app.  
The module file sits in the /lib folder.

My problem, I worked out (which I have noticed before) is that I cannot  
seem to access defined class methods in the module via the including  
class. It seems that only instance methods are available. Let me  
explain:

module MyModule  
def self.test  
“class”  
end

def test  
“instance”  
end  
end

class MyClass  
include MyModule  
end

class MyController  
my\_class = MyClass.new

test1 = MyClass.test #=\> gives an NoMethodError  
test2 = my\_class.test #=\> works  
end

Is there something I am missing here? Please note I just wrote this code  
quickly to show the idea, have not tested!  
Its not essential but seems a bit silly that I need to use an instance  
method in a situation when a class method would be much neater.

Any pointers much appreciated!

---

<div class="post-metadata">

**Author:** ![hirodusk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/6f9a4e/32.png) [@hirodusk](https://www.ruby-forum.com/u/hirodusk)\
**Post date:** [February 20, 2009, 2:43pm UTC](https://www.ruby-forum.com/t/module-include-class-instance-methods-confusion/160866/2 "2009-02-20T14:43:59Z")

</div>

Hi –

On Fri, 20 Feb 2009, Adam W. wrote:

> “class”
> 
> method in a situation when a class method would be much neater.
> 
> Any pointers much appreciated!

If you have a spare six months, you can look through the previous  
discussions of this topic on this list 🙂

Basically, the module and the class that includes it are independent  
agents, when it comes to their own singleton/class methods. The  
include operation is for the benefit of the objects that already  
consult the class for methods: it adds the module to the method lookup  
path of those objects. The class object itself is unaffected.

You can intercept the include event, though, and manipulate the lookup  
path of the class object itself. A very common pattern is:

module M  
def x  
puts “Instance method”  
end

```
 module ClassMethods
   def y
     puts "Class method"
   end
 end

 def self.included(c)
   c.extend(ClassMethods)
 end

```

end

class C  
include M  
end

C.new.x # Instance method  
C.y # Class method

The idea here is to extend (i.e., do a per-object include) the class  
object itself with a specialized module, M::ClassMethods, at the same  
time that the module M is included in the class.

The name “ClassMethods”, of course, is arbitrary; the methods defined  
in that module are instance methods of the M::ClassMethods module.  
They only become “class methods” by virtue of the extend operation.

I know it probably seems like a lot of work for something that you  
might think should be automatic, but it’s actually good that it isn’t  
automatic, because that would remove the ability to keep the singleton  
(class) methods of a given module and a given class separate. This  
way, with the out-of-the-box behavior being the more basic, there’s  
nothing you can’t do.

David

–  
David A. Black / Ruby Power and Light, LLC  
Ruby/Rails consulting & training: [http://www.rubypal.com](http://www.rubypal.com)  
Coming in 2009: The Well-Grounded Rubyist ([The Well-Grounded Rubyist](http://manning.com/black2))

Ruby Training Atlanta! April 1-3, [ruby training, atlanta, april 2009 - entp](http://www.entp.com/training/atlanta09)

---

<div class="post-metadata">

**Author:** ![hirodusk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/6f9a4e/32.png) [@hirodusk](https://www.ruby-forum.com/u/hirodusk)\
**Post date:** [February 20, 2009, 3:12pm UTC](https://www.ruby-forum.com/t/module-include-class-instance-methods-confusion/160866/3 "2009-02-20T15:12:55Z")

</div>

On Feb 20, 8:42 am, “David A. Black” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > class. It seems that only instance methods are available. Let me  
> > end  
> > end
> 
> ```
> def x
> c.extend(ClassMethods)
> 
> ```
> 
> The idea here is to extend (i.e., do a per-object include) the class  
> (class) methods of a given module and a given class separate. This  
> way, with the out-of-the-box behavior being the more basic, there’s  
> nothing you can’t do.

I think that’s a fallacious argument.

First, I would like to see an example where it would really be a  
problem. I’ve heard plenty of opinion on this, I’ve yet to see any  
hard examples where it is actually a problematic limitation.

But besides that, why can’t there be both? Let #include do it’s thing  
and have another method provide the other.

My argument for having the capability is that it provides single  
encapsulation of concerns. I have come across plenty of situations  
where the meta and instance level need to communicate. This works fine  
if your need fits the profile of a subclass. But if you need a mixin,  
then you are forced to encapsulate the two parts as separate modules,  
even though they represent a single cohesive unit of logic. We end up  
with extraneous separations of code with non-descriptive names, like  
“ClassMethods”, which is neither intuitive or naturally documenting.

T.