Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!radar!cadillac!pebbles!ned
From: ned@pebbles.cad.mcc.com (Ned Nowotny)
Newsgroups: comp.lang.c++
Subject: Re: asking an object for its type
Message-ID: <17238@cadillac.CAD.MCC.COM>
Date: 9 Mar 91 19:57:25 GMT
References: <27D57565.2B22@tct.uucp> <1991Mar7.153417.6489@linus.mitre.org> <1991Mar8.024331.14235@searchtech.com> <27D7F621.2F5@tct.uucp>
Sender: news@cadillac.CAD.MCC.COM
Reply-To: ned%cad@MCC.COM (Ned Nowotny)
Organization: MCC CAD Program, Austin, TX
Lines: 48

In article <27D7F621.2F5@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
=>According to johnb@searchtech.com (John Baldwin):
=>>Perhaps what we have here is in fact a needed extension to the language
=>>which, when not used judiciously, can be harmful.
=>
=>I would agree, except for the "needed" part.  :-/
=>
=>>Here's the real question: has anyone here needed type testing *for ANY
=>>other reason* than,
=>>      1) to implement persistent objects, or
=>>      2) to allow run-time object selection?
=>
=>I still haven't been shown why type testing is so important for
=>persistent object creation.  In other words, as an implementor of
=>persistent objects, what does isKindOf() do for you that virtual
=>functions can't or shouldn't?

The problem with persistent objects is not the frequently mentioned
one of knowing which object to construct when a given object is being
read/paged into memory.  Any system which supports persistent objects
already solves this problem in one way or another and can solve it
without ever exposing the dynamic type system to the user.  (Of course,
this does mean that there is no way to portably store objects of
classes which are provided by a different library than the persistent
object library.  However, a consistent dynamic typing mechanism is
only a partial solution.  Either persistence should be provided as a
first class facility or you live with the current situation; translate
temporary objects to/from persistent objects.)

The real problem comes up when you only have a base type pointer or
reference to an object that has been retrieved from persistent storage.
Because you no longer know how the object was created (that information
was available in the process which created the object, but not in the
current process without exporting the type mechanism of the persistence
system), you are prevented from using the specialized interface of
derived objects unless you either run that interface back up the
inheritance tree and raise exceptions when the interface is used for
inappropriate objects or you provide some alternative method to get
at an object through a reference or pointer of the appropriately derived
type.  However, both of these schemes are essentially equivalent to
providing a mechanism for determining an object's type dynamically,
only more complicated or a violation of the reuse and specialization
concepts of inheritance.

Ned Nowotny, MCC CAD Program, Box 200195, Austin, TX  78720  Ph: (512) 338-3715
ARPA: ned@mcc.com                   UUCP: ...!cs.utexas.edu!milano!cadillac!ned
-------------------------------------------------------------------------------
"We have ways to make you scream." - Intel advertisement in the June 1989 DDJ.