Re: the dark side of inherited methods

On Thu, Nov 4, 2010 at 1:24 AM, Intransition <[e-mail]> wrote:
> On Nov 2, 1:40=A0pm, Robert Klemme <[e-mail]> 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. =A0Although Bertrand Meyer is a big fan o=
f
>> implementation inheritance I am not yet convinced that it is such a good
>> idea so often. =A0Of 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. =A0I 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" <=3D> "A is a B" is so much simpler.
>> And in Ruby, whenever you need implementation inheritance you can use a
>> mixin module. =A0Enumerable 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.

I am not sure I get your point.  What do you mean by access to
Numeric.new?  Method new is defined in Class and Numeric does not have
a method #initialize:

irb(main):028:0> Numeric.ancestors.map {|cl| cl.method(:new) rescue cl}
=3D> [#<Method: Class#new>, Comparable, #<Method: Class#new>, Kernel,
#<Method: Class#new>]

irb(main):029:0> Numeric.ancestors.map {|cl|
cl.instance_method(:initialize) rescue cl}
=3D> [#<UnboundMethod: Numeric(BasicObject)#initialize>, Comparable,
#<UnboundMethod: Object(BasicObject)#initialize>, Kernel,
#<UnboundMethod: BasicObject#initialize>]

Did you mean Integer?  I describe the issue here
http://blog.rubybestpractices.com/posts/rklemme/019-Complete_Numeric_Class.=
html

Even that would only be a case of a specific class and not something
about inheritance in Ruby in general.

What is it that you find "poor" about inheritance in Ruby?

>> > 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. =A0It's not that you _need_ inheritance to have code reuse. =
=A0I
>> 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. =A0I say this because a class intended fo=
r
>> 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.

Makes me think of traits.  Scala has some nice features in that area IIRC.

http://www.scala-lang.org/node/126

> 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.

Exactly.

> 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.

What exactly would you like to have changed in the language?  So far I
always liked the simplicity and cleanness of Ruby.  But maybe
evolutions of the language are possible that will maintain the balance
yet get more out of inheritance.  I am really curios what you are
imagining.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/