# Implementation of mixins?

**URL:** <https://www.ruby-forum.com/t/implementation-of-mixins/96082>\
**Category:** Ruby\
**Created:** [June 25, 2006, 4:17pm UTC](https://www.ruby-forum.com/t/implementation-of-mixins/96082 "2006-06-25T16:17:09Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![roggan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/8c91f0/32.png) [@roggan](https://www.ruby-forum.com/u/roggan)\
**Post date:** [June 25, 2006, 4:17pm UTC](https://www.ruby-forum.com/t/implementation-of-mixins/96082/1 "2006-06-25T16:17:09Z")

</div>

How are the mixins implemented in Ruby?

are the code in the mixin module “injected” into the target class?

eg:  
consumer --call–\> Taget

or will the mixin related stuff live in some separate object and the  
target just redirects its calls to the mixin object?

eg:  
consumer --call–\> Target --redirect call–\> mixin

So, will it be a true mixin , or just a redirection mixin?

---

<div class="post-metadata">

**Author:** ![roggan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/8c91f0/32.png) [@roggan](https://www.ruby-forum.com/u/roggan)\
**Post date:** [June 25, 2006, 4:38pm UTC](https://www.ruby-forum.com/t/implementation-of-mixins/96082/2 "2006-06-25T16:38:28Z")

</div>

On 25-jun-2006, at 16:17, Roger J. wrote:

> So, will it be a true mixin , or just a redirection mixin?

The mixin works with the methods and instance variables available on  
the bearing instance

module LengthDisplay  
def show  
puts “Length is #{@len}”  
end  
end

class One  
include LengthDisplay  
attr\_accessr :len  
end

This way One will get a show method from the mixin, but you still can  
override the method in the class to get more refined behavior.  
It’s not copied - so if you change the method in the module it’s  
going to change for all the bearing classes as well.

---

<div class="post-metadata">

**Author:** ![roggan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/8c91f0/32.png) [@roggan](https://www.ruby-forum.com/u/roggan)\
**Post date:** [June 25, 2006, 5:15pm UTC](https://www.ruby-forum.com/t/implementation-of-mixins/96082/3 "2006-06-25T17:15:04Z")

</div>

Ah ok,

I dont consider redirection mixins “bad” , its just that they might  
require a bit more attention when coding atleast in other  
implementations.

are there any risks of identity problems with this in Ruby?  
(there sure is in eg. my NAspect framework for .NET where I also use  
redirection for mixins… and in that case “this” means the mixin not the  
subject)

or are the mixins “proxy aware” so to say, so the “self” pointer inside  
a mixin points to the subject and not the mixin?

---

<div class="post-metadata">

**Author:** ![roggan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/8c91f0/32.png) [@roggan](https://www.ruby-forum.com/u/roggan)\
**Post date:** [June 25, 2006, 11:45pm UTC](https://www.ruby-forum.com/t/implementation-of-mixins/96082/4 "2006-06-25T23:45:11Z")

</div>

On 25-jun-2006, at 17:15, Roger J. wrote:

> or are the mixins “proxy aware” so to say, so the “self” pointer  
> inside  
> a mixin points to the subject and not the mixin?  
> Yes, self refers to the subject. Unless you are talking about the own  
> methods of the module:

module Foo  
def self.say  
self.something # will call Foo.something  
end

```
     def fire
       self.ignite! # will call ignite! on the object whose

```

class has the module mixed in  
end  
end

---

<div class="post-metadata">

**Author:** ![roggan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/8c91f0/32.png) [@roggan](https://www.ruby-forum.com/u/roggan)\
**Post date:** [June 25, 2006, 4:57pm UTC](https://www.ruby-forum.com/t/implementation-of-mixins/96082/5 "2006-06-25T16:57:55Z")

</div>

Roger J. wrote:

> eg:  
> consumer --call–\> Target --redirect call–\> mixin
> 
> So, will it be a true mixin , or just a redirection mixin?

You say “true” like non-“redirectrion” is a bad thing. Actually it is a  
good thing. Ruby mixins work by using a proxy class which is added to  
the inheritance chain, then the mixin module is tied to that proxy  
class. The effect is essentially:

class AClass \< Mixin1 \< Mixin2 … \< SuperClass

but it does not require actual subclassing. Eg.

module AMixin  
def f; “f”; end  
end

class AClass  
include AMixin  
def f; “f” + super ; end  
end

AClass.new.f #=\> “ff”

HTH,  
T.