Implementation of mixins?

Ruby
1

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?

2

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.

3

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?

4

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

5

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.