From: ara.t.howard@... Date: 2006-06-13T02:29:46+09:00 Subject: Re: Why the lack of mixing-in support for Class methods? On Tue, 13 Jun 2006 transfire@gmail.com wrote: > > Daniel Schierbeck wrote: >> Logan Capaldo wrote: >>> Then you have multiple inheritance. >> >> Yes. > > Not really. Mulitple Inheritance provides orthogonal heirarchies. > Ruby's is strictly linear. If what you say were true then Ruby would > already be MI since modules can be used to add behavior to both class > and instance levels, and readily associated together as well, as Ara's > example clearly demonstrates. To think this consititutes MI and thus > making specialized restrictions of code separation to repress it, only > serves to complixify the situation, not the other way around. It's like > trying to prevent someone from getting to their destinatin by not > allowing them to turn right --they'll still get there, they'll just > turn left three times. > > T. in my mind it's this that makes it __not__ mi harp:~ > cat a.rb module A def foo() 'foo' end end module B def bar() 'bar' end end module C def bar() foo() end end class D include A include B include C end p D.new.foo harp:~ > ruby a.rb "foo" now, if ruby was truely mi then i could write something (imagined) like class D < (A, B, C) end p D.new.foo and ruby would be free to print either 'foo' or 'bar'. clearly it would be one or the other and a ruleset would exist to make it un-ambiguous, but the difference between ruby deciding and having built-in rules vs me deciding and have explicit call hierachies aranged manually is a rather large one. so, to me, this is the crucial thing which prevents me from considering ruby to be a true mi lang. the cool thing, of course, is that it's only a few lines of code to make is behave as if it was. cheers. -a -- suffering increases your inner strength. also, the wishing for suffering makes the suffering disappear. - h.h. the 14th dali lama