# Modules, instance methods and class methods

**URL:** <https://www.ruby-forum.com/t/modules-instance-methods-and-class-methods/70139>\
**Category:** Ruby\
**Created:** [September 27, 2006, 12:22am UTC](https://www.ruby-forum.com/t/modules-instance-methods-and-class-methods/70139 "2006-09-27T00:22:11Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![gnuvince](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/82dd89/32.png) [@gnuvince](https://www.ruby-forum.com/u/gnuvince)\
**Post date:** [September 27, 2006, 12:22am UTC](https://www.ruby-forum.com/t/modules-instance-methods-and-class-methods/70139/1 "2006-09-27T00:22:11Z")

</div>

Hello !

I have a rather tortured architecture where several classes should  
share code for some class methods and for some instance methods. To fix  
the ideas, I need that some class I define have:

def ThisClass.desc  
return @desc  
end

def desc  
return self.class.desc  
end

To do that, I define two modules

module BaseInclude  
def desc  
return self.class.desc  
end  
end

module BaseExtend  
def desc  
return @desc  
end  
end

and I include them with

class ThisClass  
include BaseInclude  
extend BaseExtend  
end

That works perfectly fine. My question, then, is : is there a simpler  
way ? I can’t afford to have a shared ancestor for these classes.

Thanks !

```
Vince
```

---

<div class="post-metadata">

**Author:** ![gnuvince](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/82dd89/32.png) [@gnuvince](https://www.ruby-forum.com/u/gnuvince)\
**Post date:** [September 27, 2006, 1:46am UTC](https://www.ruby-forum.com/t/modules-instance-methods-and-class-methods/70139/2 "2006-09-27T01:46:18Z")

</div>

Hi –

On Wed, 27 Sep 2006, Vincent F. wrote:

> end  
> include BaseInclude  
> extend BaseExtend  
> end
> 
> That works perfectly fine. My question, then, is : is there a simpler  
> way ? I can’t afford to have a shared ancestor for these classes.

Personally, I like your approach: you’ve grouped methods according to  
plan, and then carried out the plan. There are more elaborate ways,  
but this seems to work for you, and it’s very clear.

Just to point you to a couple of possible variations:

You could make the module that’s destined for the extend operation a  
nested module inside the other. In fact, you’ll sometimes see this:

module Something  
def a\_method  
end

```
 module ClassMethods
   def some_class_level_method
   end
 end

```

end

followed by:

class MyClass  
include Something  
extend Something::ClassMethods  
end

(And you can even hook the extend operation into the include operation  
by defining an appropriate self.included hook method in Something, so  
that you don’t have to have a separate extend call.)

I use the name “ClassMethods” advisedly: it’s a popular choice. It  
has the disadvantage of being inaccurate, in the sense that the  
methods inside it are instance methods. But as long as they’re  
destined to be class methods (which, after all, are really instance  
methods of the singleton class of a class!), it might be a reasonable  
name.

David

---

<div class="post-metadata">

**Author:** ![gnuvince](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/82dd89/32.png) [@gnuvince](https://www.ruby-forum.com/u/gnuvince)\
**Post date:** [September 27, 2006, 4:40am UTC](https://www.ruby-forum.com/t/modules-instance-methods-and-class-methods/70139/3 "2006-09-27T04:40:34Z")

</div>

Hi–

Vincent F. wrote:

> def desc
> 
> extend BaseExtend  
> end
> 
> That works perfectly fine. My question, then, is : is there a simpler  
> way ? I can’t afford to have a shared ancestor for these classes.
> 
> Thanks !

Not too long ago this was discussed with a length with Matz. The result  
was #class\_extension.

module Base  
def desc  
return self.class.desc  
end

```
class_extension do
  def desc
    return @desc
  end
end

```

end

class ThisClass  
include Base  
end

An excellent pure Ruby implementation of this was developed by Daniel  
Schierbeck, It can be found it the Facets project  
([facets.rubyforge.org](http://facets.rubyforge.org)). To use: require ‘facet/module/class\_extension’.  
For convenience the code follows.

It remains to be seen if Matz ultimately goes with this approach in  
Ruby 2.0. But as of yet I guess one could say it the most “official”  
technique available. (Not to say that others are prefectly valid of  
course)

T.

class Module

alias\_method :append\_features\_without\_class\_extension,  
:append\_features

# = class\_extension

# 

# Normally when including modules, class/module methods are not

# extended. To achieve this behavior requires some clever

# Ruby Karate. Instead class\_extension provides an easy to use

# and clean solution. Simply place the extending class methods

# in a block of the special module method #class\_extension.

# 

# module Mix

# def inst\_meth

# puts ‘inst\_meth’

# end

# 

# class\_methods do

# def class\_meth

# “Class Method!”

# end

# end

# end

# 

# class X

# include Mix

# end

# 

# X.class\_meth #=\> “Class Method!”

# 

def class\_extension(&block)  
@class\_extension ||= Module.new do  
def self.append\_features(mod)  
append\_features\_without\_class\_extension(mod)  
end  
end  
@class\_extension.module\_eval(&block) if block\_given?  
@class\_extension  
end

private :class\_extension

def append\_features(mod)  
append\_features\_without\_class\_extension(mod)  
mod.extend(class\_extension)  
if mod.instance\_of? Module  
mod. **send** (:class\_extension). **send** (:include,  
class\_extension)  
end  
end

end

class Class  
undef\_method :class\_extension  
end

---

<div class="post-metadata">

**Author:** ![gnuvince](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/82dd89/32.png) [@gnuvince](https://www.ruby-forum.com/u/gnuvince)\
**Post date:** [September 27, 2006, 11:10am UTC](https://www.ruby-forum.com/t/modules-instance-methods-and-class-methods/70139/4 "2006-09-27T11:10:27Z")

</div>

Hello !

> ```
> return @desc
> 
> ```
> 
> ([facets.rubyforge.org](http://facets.rubyforge.org)). To use: require ‘facet/module/class\_extension’.  
> For convenience the code follows.

Thanks !

> It remains to be seen if Matz ultimately goes with this approach in  
> Ruby 2.0. But as of yet I guess one could say it the most “official”  
> technique available. (Not to say that others are prefectly valid of  
> course)

That would be cool if the syntax could be somewhat lighter: it somehow  
doesn’t look right to me to have the code within a block. But that’s  
just aesthetics… And that would be for ruby 2.0, if I understand  
right.

Cheers !

```
Vince

```

---

<div class="post-metadata">

**Author:** ![gnuvince](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/82dd89/32.png) [@gnuvince](https://www.ruby-forum.com/u/gnuvince)\
**Post date:** [September 27, 2006, 12:16pm UTC](https://www.ruby-forum.com/t/modules-instance-methods-and-class-methods/70139/5 "2006-09-27T12:16:32Z")

</div>

Hi –

On Wed, 27 Sep 2006, Vincent F. wrote:

> > course)
> 
> That would be cool if the syntax could be somewhat lighter: it somehow  
> doesn’t look right to me to have the code within a block. But that’s  
> just aesthetics… And that would be for ruby 2.0, if I understand right.

I agree; it seems odd to resort to a block when generally the  
inclusion/extension mechanism involves modules. Also, the terminology  
is a bit narrow; it should really be ‘includer\_extension’ or  
something, since modules can be included by modules as well as  
classes.

David

---

<div class="post-metadata">

**Author:** ![gnuvince](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/82dd89/32.png) [@gnuvince](https://www.ruby-forum.com/u/gnuvince)\
**Post date:** [September 27, 2006, 3:26pm UTC](https://www.ruby-forum.com/t/modules-instance-methods-and-class-methods/70139/6 "2006-09-27T15:26:55Z")

</div>

removed\_email\_address@domain.invalid wrote:

> > > module Base
> 
> inclusion/extension mechanism involves modules.  
> Yea. I get the same vibe. There’s no precedence for it so it doesn’t  
> seem very Rubyish. But at the very least I’m happy to have something  
> that works well. Also it doesn’t require any changes under the hood so  
> I imagine it’ll just be part of the standard library, nor core. Ideally  
> though I still tend to favor an alternate to #include, eg  
> #include\_with\_class\_extension, or something (though that name is way  
> too long). But a solution like that does require some changes to Ruby  
> itself --it’s not possible to implement in plain Ruby.

> Also, the terminology  
> is a bit narrow; it should really be ‘includer\_extension’ or  
> something, since modules can be included by modules as well as  
> classes.

I think “class” is referring to the singleton, which is a class in  
etither case.

T.