From: James Coglan <jcoglan@...>
Date: 2009-08-06T22:12:50+09:00
Subject: Re: Kernel's module methods?

--001636d34bf8387ba1047078e0f3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

2009/8/6 James Gray <james@grayproductions.net>

> On Aug 6, 2009, at 7:32 AM, Brian Candler wrote:
>
>  James Coglan wrote:
>>
>>> I think the point being raised is that when you mix a module into a
>>> class,
>>> the class gains the module's instance methods, but not its
>>> module/singleton
>>> methods. So it seems that the only way you'd be able to call Kernel's
>>> module
>>> methods without a receiver would be if `self` were equal to `Kernel`.
>>>
>>
>> Yes, but are you sure they are module methods, not just instance
>> methods?
>>
>
> They are "module functions" actually, implemented with this:
>
> ------------------------------------------------- Module#module_function
>     module_function(symbol, ...)    => self
> ------------------------------------------------------------------------
>     Creates module functions for the named methods. These functions
>     may be called with the module as a receiver, and also become
>     available as instance methods to classes that mix in the module.
>     Module functions are copies of the original, and so may be changed
>     independently. The instance-method versions are made private. If
>     used with no arguments, subsequently defined methods become module
>     functions.


Thanks for pointing that out, I wasn't aware of it. Reminds me of a neat
trick for adding a module's instance methods to the same module as singleton
methods:

module MyMod
  extend self
end

Any instance methods from MyMod (and modules it includes) will appear as
singleton methods on the MyMod object. It differs from #module_function in
that the methods are not copied, so if you change MyMod#foo, MyMod.foo will
be updated to reflect the new method.

--
James Coglan
http://jcoglan.com

--001636d34bf8387ba1047078e0f3--