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

Probably.  As a (very) general rule of thumb, if you can avoid a
reference to a hard coded class name, the more flexibility you gain. 
Its so easy within in the Foo class to just say "Foo.new", and most
people do so ... with possible problems for derived classes.  Saying
"self.class.new" instead of "Foo.new" will avoid the problem you
describe.  The problem is retraining class writers (myself included) to
do it the right way.

On Sun, 2002-10-27 at 15:08, William Djaja Tjokroaminata wrote:
 
> 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.  

It can occur anytime a class makes assumptions about the concrete type
of objects that it creates.  There is always the possibility that a
derived class would like a different set of objects created.  This
problem has little to do with static vs dynamic typing and can easily
occur in C++ programs.

On a side node (a mild rant) ...

> In a "typeless" language such as Ruby,

Ruby is hardly "typeless".  It has all kinds of types.  Types are a very
important part of programming in Ruby. (end of mild rant)

-- 
-- Jim Weirich     jweirich / one.net    http://w3.one.net/~jweirich
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)