From: Robert Dober Date: 2010-11-05T04:30:23+09:00 Subject: Re: the dark side of inherited methods On Thu, Nov 4, 2010 at 1:24 AM, Intransition wrote: > 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. > Completely share this impression and I agree that it is a pity. I am not sure I completely agree with any opinion stated here but most of them have made some points I was not completely aware of. Cheers R. -- There are worse things than having people misunderstand your work. A worse danger is that you will yourself misunderstand your work. -- Paul Graham