Path: utzoo!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: asking an object for its type
Message-ID: <4325@lupine.NCD.COM>
Date: 10 Mar 91 02:41:19 GMT
References: <27D57565.2B22@tct.uucp> <1991Mar7.153417.6489@linus.mitre.org> <1991Mar8.024331.14235@searchtech.com>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 32

In article <1991Mar8.024331.14235@searchtech.com> johnb@searchtech.com (John Baldwin) writes:
+
+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?
+
+If not, then maybe what we really need is simply language support for
+persistence.  I *know* how painful it is to implement a cohesive and
+consistent object storage utility from scratch!  Yes, when it was
+finished, we had something which was (more or less) optimized for
+our particular use, but there was no reason why the language or the
+library could not have provided efficient *standardized* support for this.
[...]
+I guess before I can form an opinion or take a stand, I'd need to know
+which is the actual case: dynamic typing needed directly by the programmer,
+or just better support for persistence??

I think that "persistance" (or more precisely, the ability to get objects
out of one address space and into another reliably) is all that's really
needed.  Unfortunately, C++ itself doesn't have any standardized way of
supporting that, nor is it likely to in the forseeable future unless there
can be some concensus among the various groups who have developed solutions
to this important problem.  Those groups should first form a concensus
and then present a mutually agreeable proposal to x3j16.  Otherwise, all
of the various ad-hoc (and non-protable) schemes will continue to proliferate.

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// New motto:  If it ain't broke, try using a bigger hammer.