From: Austin Ziegler <halostatue@...>
Date: 2005-09-30T22:48:07+09:00
Subject: Re: Operator Overloading <<

On 9/30/05, Bob Hutchison <hutch@recursive.ca> wrote:
> On Sep 30, 2005, at 8:04 AM, Austin Ziegler wrote:
>> On 9/30/05, Robert Klemme <bob.news@gmx.net> wrote:
>>> Pardon me, but this is nonsense: Matt has *inherited* Array.  Of
>>> course you can argue about whether *that* is reasonable, but once
>>> you did that providing your own implementation of a super class
>>> method in a derived class is completely standard OO.  There's even a
>>> keyword to support this ("super").
>> And all of that still works with Delegate. I know, because I *just*
>> did it for some code that won't see the light of day for a while.

>>> If you wanted to question the practice of inheriting classes like
>>> Array and String then I'm completely with you.  This doesn't make
>>> sense more often that it does.  But I know too little of this
>>> particular case to further comment on that.
>> That's really what I was trying to say here. Yes, the idea is *don't*
>> inherit from Array. You can't overload in Ruby, you can override and
>> you have to call super to make it work, or you have to call it
>> directly with aliasing.
> Where do you stop? Why inherit at all? How do you decide?

Sorry, but this really doesn't have anything to do with my statement.
One shouldn't inherit from Array, String, and Hash in Ruby because there
are certain things that Don't Work the way that you'd expect them to
because they are written in the C side.

In general, I don't have a problem with inheritance -- it should be used
smartly -- but in this specific case, inheriting from certain of Ruby's
core classes is enough of a problem that you do *not* want to do that.

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca