Brian Candler <B.Candler / pobox.com> wrote:
> I also find this interesting, as it's a side-effect of subclassing I hadn't
> thought about.

> Somewhere deep in the innards of String#+ it is doing the equivalent of a
> String.new; should it be doing a self.class.new instead?

> Put more philosophically: is it the responsibility of a class author to
> consider the requirements of possible future subclasses, in particular to
> make sure that inherited methods have the 'right' behaviour in the context
> of a subclass?

> If not, then the subclass will end up having to wrap those methods - i.e.

>   class S
>     def +(arg)
>       S.new(super)
>     end
>   end

> That's ugly, and it seems like it was hardly worth inheriting the method in
> the first place. [1]

> The 'new' method which was inherited by S (or at least gives the appearance
> of being inherited) doesn't need a wrapper though: S.new returns an S, not a
> String. Perhaps that's why it's surprising that the inherited S#+ returns a
> String not an S.

> Regards,

> Brian.

> [1] That doesn't apply to _all_ inherited methods - e.g. the inherited '<=>'
> is perfectly good - just methods which return String in this case

Hi Brian,

I agree with everything that you said.  I guess in a typed language such
as C++, this is not a problem, because the same data (i.e., bit
patterns) can be interpreted differently based on the type of the variable
that is used to access the data.  In a "typeless" language such as Ruby,
on the other hand, the type itself is carried in the data, and therefore I
got this "surprise".

I personally don't know which is the "right" way to do OO design.  Whereas
a question such as the lack of Boolean parent class in Ruby is
probably more theoretical than practical, a question like this is I think
very practical, because it dictates the whole OO design.  I am rather
disappointed actually, because very few (or almost none of the) people
who usually discussed OO-related issues state their opinions.  (Or
probably this is just one of the "unsolved problems" in Ruby, along with 
others like private variables and block local variables?)

Regards,

Bill