Forum: Ruby module include class/instance methods confusion!!

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
0c70d7ecd4853d40fc8a026ab870334f?d=identicon&s=25 Adam Wilson (adamski)
on 2009-02-20 14:01
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!
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-20 14:43
(Received via mailing list)
Hi --

On Fri, 20 Feb 2009, Adam Wilson 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
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-02-20 15:12
(Received via mailing list)
On Feb 20, 8:42 am, "David A. Black" <dbl...@rubypal.com> 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.
This topic is locked and can not be replied to.