[ruby-core:65447] [ruby-trunk - Feature #9112] Make module lookup more dynamic (Including modules into a module after it has already been included)

Issue #9112 has been updated by Xavier Noria.


+1 over here.

I remember I discovered this the hard-way extracting some code from Rails into a gem.

I believe the current behavior is a leak of the implementation. Conceptually, in my opinion, a method or constant lookup should follow the ancestor chain at that point in runtime. That way you can add behavior to modules adding method directly or via another module for organizational purposes.

I have always seen the linearization of ancestors as an implementation detail not belonging to the conceptual object model of Ruby. From the user perspective it does not matter if there's a pointer to super, or if there's a tree search of some sort going on.

That's my view, don't really know if it's also the view of Ruby core.

I asked Matz about this in the past and he said what was said above, that if there was no performance penalty it would be open to this change. See

https://www.ruby-forum.com/topic/1458576


----------------------------------------
Feature #9112: Make module lookup more dynamic (Including modules into a module after it has already been included)
https://bugs.ruby-lang.org/issues/9112#change-49233

* Author: Tobias Pfeiffer
* Status: Assigned
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category: core
* Target version: 
----------------------------------------
If a module (M) is included into a class (C) and afterwards another module (M2) is included into the first module (M) then C does not include M2 and instances do not respond to methods defined in M2. I think instances of C should respond to methods defined in M2 and C should include M2.

I created a gist detailing the problem I have: https://gist.github.com/PragTob/7472643

I think this behavior is confusing, because if I'd reopen module M and just add methods there then instances of C can call those methods. However if I include another module in M then instances of C can not call those methods.

Any opinions on if this would be a better behavior or why it isn't?

(was unsure to file it as a bug or feature)



-- 
https://bugs.ruby-lang.org/