Ruby 1.9 - Change of included modules behaviour?

Ruby
1

I’m just wondering if the behaviour of included modules is expected to
change in Ruby 1.9.

This question has been raised from the following thread :

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/241164

As of Ruby 1.8, it seems that included modules have a behaviour
similar as class variables/methods.

module M
end

class B
include M
@@var = “Hello”
end

class C < B
end

p C.ancestors # => [C, B, M, Object, Kernel]

class C
include M
end

p C.ancestors # => [C, B, M, Object, Kernel]

The class variable @@var is shared/inherited from B.
Likewise, the module M is shared from B and is not included directly
by C.

Conversely :

module M
end

class B
end

class C < class B
include M
@@var = “Hello”
end

class B
include M
@@var = “Goodbye”
end

p C.ancestors # => [C, M, B, M, Object, Kernel]

The two class variables @@var are different.
Likewise, the module M is include both by C and by B.

Question :
As of Ruby 1.9, a class variable/method will be static to the class.

What about the included module ?
Is is planned that including a module is “static” to the class ?
Thus, if a class C include M, M is actually included by C
independently of the fact that M is included or not by a superclass of
C.

Thanks for any clarification.

2

On 3/1/07, Ruby A. [email protected] wrote:

I’m just wondering if the behaviour of included modules is expected to change in Ruby 1.9.

Just to bring the discussion over to this thread.

The version of Ruby 1.9 sometime around last October changed this so
that
including a module in a subclass which was already included in a
superclass would re-include it:

module M
end

class C
include M
end

class D < C
end

class E < C
include M
end

In Ruby 1.8 the inheritance chain for E would be

[E, D, M, C, Object, Kernel]

and in the old 1.9 it would be:
[E, M, D, M, C, Object, Kernel, BasicObject]

as of today’s build 1.9 gives
[E, D, M, C, Object, Kernel, BasicObject]

Note that this will have different semantics in the case that an
intervening class like D re-defines a method inherited from M, with
the 1.8 semantics, E can’t get the method from M by reincluding M.

I’m not sure why this changed back or whether it will stay that way.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/