Bug #8298: Module include inconsistency

• Status: Rejected
• Assignee: -
• Target version: 2.1.0
• ruby -v: 1.8, 1.9, 2.0
• Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN

[Student (Nathan Zook)]

It has been suggested that I report this as a violation of the object model:

module M ; end
module N ; end
class C ; include M ; end
module M ; include N ; end
c = C.new
c.extend M
d = class << c ; self ; end
d.ancestors
=>[N, C, M, Object, Kernel]

This has been this way for a while...

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Rejected

This is official restriction on module mix-in.

1. modifications to modules after they are included would not be change existing relation, thus N will not be included to C.
2. #include does not add already included modules, thus M will not be included to c.singleton_method (but N will be).
3. #ancestors on a singleton classes does not show the singleton class itself.

The last one might be considered as a bug. But we have no plan to fix others.

Matz.

[Student (Nathan Zook)]

I think that perhaps I was too brief. My complaint is only that N precedes M (and C) in the ancestor list. The other matters are clear.

module M ; def foo ; M ; end ; end
module N ; def foo ; N ; end ; end
class C ; include M ; end
module M ; include N ; end
c = C.new
c.extend M
c.foo
=> N

class D ; include M ; end
D.new.foo
=> M

[marcandre (Marc-Andre Lafortune)]

Student (Nathan Zook) wrote:

I think that perhaps I was too brief. My complaint is only that N precedes M (and C) in the ancestor list. The other matters are clear.

Indeed, it is a bit surprising. When including M, it manages to include N (because it's not in the ancestor list because of (1)) and then won't include M itself, because of (2).

For the record, (3) is already changed in trunk. I still hope to see (1) and (2) addressed one day.