From: Intransition Date: 2010-11-04T09:24:44+09:00 Subject: Re: the dark side of inherited methods On Nov 2, 1:40 pm, Robert Klemme wrote: > On 02.11.2010 17:37, Intransition wrote: > > Indeed, I think inheritance gets a really bad rap in Ruby b/c Ruby's > > base classes and inheritance system are so poorly designed to handle > > it. > > I would not subscribe to that.  Although Bertrand Meyer is a big fan of > implementation inheritance I am not yet convinced that it is such a good > idea so often.  Of course, there are always uses for any technique > present, but I find the "is a" relationship interpretation of > inheritance so clear and obvious that I somehow feel bad about polluting > inheritance with other uses.  I cannot really put forward a more > concrete argument or even back this up by some hard (business) numbers, > but a world in which "A inherits B" <=> "A is a B" is so much simpler. > And in Ruby, whenever you need implementation inheritance you can use a > mixin module.  Enumerable is a very good example for that. Mixins are just another way to do inheritance. It has the same issues. The only difference is the module level --and that's just an arbitrary deviation often circumvented by "ClassMethods" hacks.. To the main point of Ruby's poor handling of inheritance, I should give an an example. Consider creating a subclass of Numeric. We have no access to the `Numeric.new`, so a subclass of Numeric is actually a trick. Such a class would (by necessity) work just as well without the numeric superclass. The only reason for the superclass is so that `is_a?(Numeric)` will work. > > The other day I was talking to my Father, a Cobol programmer from back > > in the day, and he was telling me that when he retired, OOP was just > > starting to get hyped. He was quite interested in it at the time and > > then rattled off some of the advantages he remembered it was to bring > > to the field. Inheritance for code reuse was high on the list and > > Well, there are other forms of code reuse - even in procedural > languages.  It's not that you _need_ inheritance to have code reuse.  I > would even go as far as to claim that it is more difficult to implement > classes intended solely for implementation inheritance than classes > which implement a particular real world concept and which are only > inherited if "is a" is needed.  I say this because a class intended for > implementation inheritance needs other criteria for including > functionality than a class which implements a particular concept. I think implementation inheritance becomes easier if classes are kept small with simple APIs and focused on a limited goal. Then larger "real world" classes are built up by inheriting from these smaller abstractions. But to have a really robust system to do this, one needs some tools that Ruby doesn't provide, such a private inheritance, probably class private instance variables and methods, and better multiple inheritance than Ruby's mixin system. I think there is a place for both inheritance and composition. It's not an all or nothing deal. I think Enumerable is actually a great example of the power of inheritance when used well. And I think Ruby would be even better if it took that idea and ran with it a bit further. > Btw, I find that we have this type of discussion far too seldom here > nowadays and I imagine that we did that more often earlier on.  But that > is totally subjective. Agreed.