From: Luke Ivers Date: 2007-01-25T02:19:49+09:00 Subject: Re: Trickery in the ancestors chain On Thu, 25 Jan 2007 01:55:07 +0900 "Phrogz" wrote: > On Jan 24, 8:48 am, ara.t.how...@noaa.gov wrote: > > harp:~ > cat a.rb > > # > > # take one > > # > > module M > > def hello; 'M'; end > > end > > class C > > def hello; 'C'; end > > end > > class D < C; end > > class C; include M; end > > class D; include M; end > > p D.ancestors #=> [D, C, M, Object, Kernel] > > I think the issue here is that essential no-op: > > module M; end > class C; end > class D < C; end > > class C; include M; end > x = D.ancestors > class D; include M; end > y = D.ancestors > > p x==y > #=> true > > The issue is that Ruby says "Hey, M is already in your ancestor > list...I'm going to prevent you from inserting it into the chain at a > lower level." > > Seems like a bug, like it should only prevent the M inclusion if it's > already included directly in the class. > > Yeah, but isn't this a dangerous road to go down? You will end up with people including a module to get some functionality and re-over-writing inherited methods that were over-writing instance methods in the original module. I guess we should be allowed to do that, but it's probably going to cause more headaches to do it that way than it's going to solve... if you really need to use the original definition of a module's instance method that's been over-written already by a superclass, you have to question why you're using that superclass at all... if you don't want its functionality, but the functionality of something that it's inheriting, maybe you should consider some other sort of object hierarchy? -- Luke Ivers