Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.lang.c++
Subject: Re: asking an object for its type
Message-ID: <1991Feb20.203533.7142@odi.com>
Date: 20 Feb 91 20:35:33 GMT
References: <23984@netcom.COM> <1190@sheol.UUCP> <1991Feb19.000449.22255@gpu.utcs.utoronto.ca> <607@taumet.com>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 27
In-Reply-To: steve@taumet.com's message of 19 Feb 91 16:07:24 GMT

In article <607@taumet.com> steve@taumet.com (Stephen Clamage) writes:

   All you have to do is make a virtual function diameter() for all Shapes.
   A function which expects to operate on a class of type Shape may
   reaonably expect all the functionality of Shape to be present.  It may
   not reasonably expect specific behaviors of classes derived from Shape
   to be present.

In addition to what other people have mentioned, this approach isn't
very good from the point of view of extensibility.  Suppose that we
are trying to make an extensible graphics system.  We would like a
programmer-extended to be able to add new kinds of shapes, by
subclassing Shape.

Suppose a programmer wants to add Ellipses which has major_axis and
minor_axis function members, and we'd like be able to ask for all
shapes being displayed that are Ellipses with minor_axis greater than
7.  Using your approach, we have to modify Shape, to add these two
function members to it, so that all Shapes can accept the minor_axis
function member.  But the whole idea of extensibility of this sort is
that it should not be necessary to modify the base class.  After all,
the base class might have been written by someone else; new versions
of it might be issued, and then you'd have to merge in all your local
changes (like minor_axis) every time, etc.

I don't think there's an obvious quick fix for this issue, but I do
think it's worthy of being acknowledged as a problem.