# ClassMethods: Module creation hook / Capitalized method

**URL:** <https://www.ruby-forum.com/t/classmethods-module-creation-hook-capitalized-method/49131>\
**Category:** Ruby\
**Created:** [November 30, 2005, 2:36pm UTC](https://www.ruby-forum.com/t/classmethods-module-creation-hook-capitalized-method/49131 "2005-11-30T14:36:17Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\
**Post date:** [November 30, 2005, 2:36pm UTC](https://www.ruby-forum.com/t/classmethods-module-creation-hook-capitalized-method/49131/1 "2005-11-30T14:36:17Z")

</div>

I’m sure everyone knows about the ClassMethods technique for getting a  
module’s class/module methods to be inherited. I have come up with an  
improvement on this, but rather than define a ClassMehthods module  
manually one supplies a block to a method. It still creates the  
ClassMethods module, but it does so using the block. If there were a  
way to hook into module creation that wouldn’t be neccessary. But is  
there a way to hook into this?

On the other hand sticking with the block method, I realized I could  
use a capitalized method name without inherfereing witht the module  
(they exist in separate namespaces). So…

module Foo

```
ClassMethods do
  def x ; 1 ; end
end

```

end

class Bar ; include Foo ; end

Bar.x #=\> 1

Using a capitalized method like this, is it a good idea b/c it  
corresponds to the module name, or a bad idea b/c it does against  
convention?

Note how the above is equivalent to:

module Foo

```
module ClassMethods
  def x ; 1 ; end
end

extend ClassMethods

```

end

The block method does the extending for you.

Thanks,  
T.

---

<div class="post-metadata">

**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\
**Post date:** [November 30, 2005, 4:42pm UTC](https://www.ruby-forum.com/t/classmethods-module-creation-hook-capitalized-method/49131/2 "2005-11-30T16:42:24Z")

</div>

Hi –

On Wed, 30 Nov 2005, Trans wrote:

> I’m sure everyone knows about the ClassMethods technique for getting a  
> module’s class/module methods to be inherited.

I didn’t know there was a widely-known or standard technique of that  
name (and I wouldn’t use the term “inherited” to describe what happens  
to methods in modules; it muddies the waters a bit), but if you mean  
the kind of thing that’s done in ActiveRecord and related libraries to  
promote instance methods of a module to pseudo-class-methods of  
classes that include the module’s containing module, then yes 🙂  
(I say “pseudo” because they’re not actually class methods, but they  
end up being useable as if they were.)

> module Foo
> 
> ClassMethods do  
> def x ; 1 ; end  
> end

I think the pseudo-ness of the class method-ness of these methods is  
an issue here. You’re really redefining the notion of a class method;  
it’s no longer a singleton method of a class object. I imagine  
some counter-argument involving the word “duck” could probably be  
developed… 🙂 But I’m personally not a big fan of just asserting  
that something is a class method when that’s really not the right term  
for it. (I have the same problem with the ClassMethods module  
technique. It works by a kind of consensus, but I don’t consider it  
an optimal naming scheme.)

> end
> 
> class Bar ; include Foo ; end
> 
> Bar.x #=\> 1
> 
> Using a capitalized method like this, is it a good idea b/c it  
> corresponds to the module name, or a bad idea b/c it does against  
> convention?

I’m confused – do you have a ClassMethods module lurking somewhere?

David

---

<div class="post-metadata">

**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\
**Post date:** [November 30, 2005, 6:36pm UTC](https://www.ruby-forum.com/t/classmethods-module-creation-hook-capitalized-method/49131/3 "2005-11-30T18:36:01Z")

</div>

David A. Black wrote:

> I didn’t know there was a widely-known or standard technique of that  
> name (and I wouldn’t use the term “inherited” to describe what happens  
> to methods in modules; it muddies the waters a bit), but if you mean  
> the kind of thing that’s done in ActiveRecord and related libraries to  
> promote instance methods of a module to pseudo-class-methods of  
> classes that include the module’s containing module, then yes 🙂  
> (I say “pseudo” because they’re not actually class methods, but they  
> end up being useable as if they were.)

We’ve talked about this before. And I’m not sure we need to get into it  
again, but I don’t see how you say they are not class methods when the  
module is being included (extended) into the class adhoc (i.e. it’s  
singleton).

> I think the pseudo-ness of the class method-ness of these methods is  
> an issue here. You’re really redefining the notion of a class method;  
> it’s no longer a singleton method of a class object. I imagine  
> some counter-argument involving the word “duck” could probably be  
> developed… 🙂

But classes already work this way! How does allowing modules do the  
same thing change any such notion?

> But I’m personally not a big fan of just asserting  
> that something is a class method when that’s really not the right term  
> for it. (I have the same problem with the ClassMethods module  
> technique. It works by a kind of consensus, but I don’t consider it  
> an optimal naming scheme.)

Well ask Nodu about it, AFAIK he was the originator of the idea:

[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/35979](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/35979)

Personally I had been calling it ClassInheritable (though you probably  
think that’s even worse) but since ClassMethods is commonly used I  
figure it best to stick with whats known. I agree it may not be the  
best name --a bit overly general IMO, but then again I think this  
should be the default behavior in the first place and a seprate module  
ought to be needed to NOT inherit along the singleton chain --as you  
are aware frm the RCR.

> I’m confused – do you have a ClassMethods module lurking somewhere?

Presently you can find both ClassMethods and #class\_inherit in the  
latest Facets. These will be usurped by an improved melding of the two  
available in Calibre, which I am tweaking presently which is why I  
brought this thread up.

T.

---

<div class="post-metadata">

**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\
**Post date:** [November 30, 2005, 7:16pm UTC](https://www.ruby-forum.com/t/classmethods-module-creation-hook-capitalized-method/49131/4 "2005-11-30T19:16:31Z")

</div>

Hmmm…it’s just occured to me that others may have “tweaked out” there  
usage of ClassMethods so my lib might cause interference --unlikely but  
it could happen. So I think I’ll rename it to be on the save side.  
Thanks for making me think of that David.

T.

---

<div class="post-metadata">

**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\
**Post date:** [November 30, 2005, 7:12pm UTC](https://www.ruby-forum.com/t/classmethods-module-creation-hook-capitalized-method/49131/5 "2005-11-30T19:12:28Z")

</div>

Hi –

On Thu, 1 Dec 2005, Trans wrote:

> [http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/35979](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/35979)

OK: Nobu, don’t you think there’s a distinction between class methods  
that are defined on one particular class, and methods that are  
defined as instance methods in another context and made available to  
many classes via a module? 🙂

I think it’s partly a matter of there not being a language-level  
definition of “class method” (which is actually OK with me). If there  
were, I would tend to equate it with MyClass.singleton\_methods(false),  
rather than MyClass.singleton\_methods. Maybe that’s an artificial  
distinction, though, from the perspective of the user.

Come to think of it, it’s a bit odd that there’s such a thing as an  
object’s “singleton” methods that aren’t defined in the object’s  
singleton class. Maybe that’s the lump under the carpet that doesn’t  
seem to want to disappear in all of this.

David