From: "Chr. Rippel" Date: 2002-01-24T08:15:09+09:00 Subject: Re: ruby 2.0; rubicon "Mathieu Bouchard" wrote in .... > > oh, then that's: (Module.nesting[0] || ::Object).constants > > right? No it is the union of constants for all scopes in Module.nesting. Module.nesting.inject([]) {|union,scope| union |= scope.constants} These are exactly those constants visible at the particular point (binding) - so maybe something like Kernel#visible_constants might be a more enlightening name. .... > That's not it. The languages known for their mixin inheritance are > CommonLisp and Self, and they do it with an oriented cycle-free > graph. They remove duplicates by themselves. In Ruby it's the same except > that in addition to removing duplicates in a similar way, you can't add > supermodules to supermodules in a meaningful way. Unfortunately I don't know CommonLisp and Self beyond the point of browsing through a couple links. From what what you are writing I cannot make out if these graphs in general encompass more than simple trees/forests? (in the former case the lookup path ambiguities need to be resolved by some sort of convention like inclusion order etc, in other words, ``the way the inclusion graph was build up''). Anyway I strongly agree with you that it would be great if Ruby would sport some sort of ``reverse inheritance'' (transitive inclusion, supermodules of supermodules or "put your favorite term"). Maybe will see something like this Rite? /Christoph PS. Ruby's mixin always allowed for cycles and I never understood why this is possible (in particular since it is sooo trivial to put a guard against this kind of abuse.) ----- module A def a @a-=1 unless @a <= 0 print "in A, "; b else puts "\nfinished" end end end module B include A def b() print "in B, "; a end end module A include B end class Circle include A def initialize @a =5 end end puts A <=> B # => -1 puts B <=> A # => -1 Circle.new.b ----- -1 -1 in B, in A, in B, in A, in B, in A, in B, in A, in B, finished