From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Covariant Types in Derived Classes
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 24 Jul 1992 18:44:31 GMT

In article <VKE52M@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>So far we have seen that RTTI is very useful for debuggers, class browsers,
>report generators, user interface tools, databases, communications...
>in other words, for a great deal of the programming tools a C++ programmer
>would like to have.

	Yes. All these require a fixed piece of code to be able to
manipulate arbitary objects, right?

	If you want to add RTTI to facilitate this, I have no
argument.  I might argue, however, that such systems---
tools for manipulating C++ itself, introspective you called them,
I called them 'meta' systems, and also for interfacing to
foreign interfaces--- are a different class than garden
variety programs---domestic systems. I would like to 
see domestic systems protected from such power.

Lets suppose you allow domestic programs access to all type info.
Then there's not much point hiding the implementation is there?

However, I think what is proposed is MUCH more limited than this.
So it won't give you what you want, but it will encourage
and allow bad style in domestic programs.

	Note that what YOU want for the introspective
systems doesn't involve downcasting, it involves
MUCH deeper penetration into the system, all such systems
have to get at details that ought to be hidden in
domestic systems.
>
>>	To make proper output *requires* programmer definition,
>>when I need this I just have a virtual print in all relevant classes.
>>Of course, then I have to *write* the definitions, which is a pain.
>
>But providing a default which may be used directly or edited with
>a mouse is not a pain, and is easily provided as a general tool.

	OK.
>
>Let me give you an example from POET, the OODB that I know
>best (because I am one of the developers).  Let's say you have
>an arbitrary class declaration:
>
>	class ArbitraryClass {
>		int foo;
>	public:
>		float goo;
>	};
>
>If you just write the little word "persistent" in front of this then
>our precompiler will know that it should generate run time type info:
>
>
>	persistent class ArbitraryClass {
>		int foo;
>	public:
>		float goo;
>	};
>
>If an object is assigned to a database then you can store it using
>the Store() method, which is provided for all persistent objects:
>
>	ArbitraryClass ArbitraryObject;
>
>	ArbitraryObject->Assign(ADatabase);
>	ArbitraryObject->Store();
>
>I'll avoid going into more detail right now, but you see that this
>is very convenient.  Without RTTI it is not possible.  We do not need
>a reflective system, but we do need an introspective system.  Since
>C++ is not introspective, we have built our own compiler to give us the
>information which all C++ compilers generate and then throw away.

	So for this RTTI is needed. It HAS to know the
implementation details! It CAN break the system, so you
had better buy a good OODB like POET :-) that you trust.
>
>I am concerned that many C++ programs downcast without any guarantee
>of type safety.  Start reading large C++ programs and you will see that
>downcasts are quite common.  Is the C++ community worse off if we provide
>a safer way to do this?

	In domestic programs it would best to bad downcasts :-)
They not necessary. And the're not possible for virtual bases,
so I make all my bases virtual to make absolutely sure you
cant break the type system. I dont want you to be able to do
it safely---I dont want you to be able to do it at all!

For the same reason I dont want to to access the private variables.
Saying 'but you need to do that for a debugger, an OODB etc'
is saying something true: but that doesnt mean I want you to be
able to do it domestically. The same argument could be used
to say 'lets get rid of private and make everything public'

I dont want this domestically,
and downcasting is precisely the same issue.

>
>>	The problems you want to solve (me too, and many others :-)
>>are way out of te scope of a traditional language which
>>works only with memory resources. THAT is the problem, really.
>
>Naw.  The problems *I* am discussing have  already been solved
>using C++, but we are finding sneaky ways to get at run time type
>information.

	Exactly. You want a dynamic system. C++ is static
and somewhat typesafe because of that. You want to do something
that cant be done safely in the first place.  So C++
is the wrong tool, it is restricted to PREVENT the sort of program
you want to write being written.

	i agree to extend its scope, provided that this can be
done without prejudicing the safety of domestic systems,
which are the pricipal goal (all those debuggers are not
going to be used *just* to debug themselves!)

	So I'm NOT against RTTI, or what you want to do with it,
I'm sure thats why Bjarne is supporting it. I want to
do those sorts of things TOO.

>
>>	Wouldn't you rather just say 'persistent' and have the object
>>just exist in the 'persistent'  database totally automatically :-)
>
>	Because the user shyould have some control over which objects
>	get stored, and should be able to test the store operation for
>	error returns.  But you have the right idea!  And if you look
>	at my sample code given above--from a commercial system that
>	is now available--you see that this kind of high level access
>	is possible in C++ today, given RTTI.

Sure. We agree here. Just not about the need or advisability
of downcasting in domestic, statically determined programs.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Xref: sparky comp.lang.c++:11842 comp.std.c++:1004