From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Language extensions for run-time type identification
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 23 Jul 1992 17:41:58 GMT

In article <1992Jul21.094204.20100@mole-end> mat@mole-end writes:
>In article <1992Jul20.220534.1365@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
>
>> I sencond this. As I already said, run time type checking of classes
>> only with virtual functions is not a serious solution.
> 
>> David Shang
>
>Let's be sure that we are talking about the same thing, then I'll ask you
>to refute an assumption underlying the current proposal.
>
>The current proposal would allow a number of things, including at least
>checked downcasting and some kind of comparison-for-equality of the exact
>type of objects.
>
>There are many bad uses for these facilities, but there are also good
>uses, or so it is believed.
>
>The assumption underlying the decision to include only classes with
>virtual functions is that a class that has no polymorphic behavior
>whatsoever (not even a virtual destructor) cannot be used in any way
>that is both safe and interesting even with the proposed runtime type
>support.  Can you refute this assumption?
>-- 
	Before I start: I'm not against adding RTTI. But allow
me to play 'devils advocate' as hard as I can. :-) Convince
me that downcasting is a good thing, for example.

	What is the basis for this assumption?

	On the contrary, polymorphism BY NATURE, provides the 
correct mechanism for accessing the exact object, it is 
especially in this case that casting is not only dangerous
but unnecessary.

	In the discussion about RTTI I have participated in with David,
we agree on at least one thing: RTTI is required for writing Debugger.
Clearly a debugger needs access to ALL the type information,
so mere safe downcasting and comparison for equality would not be
adequate, nor a restriction to classes with virtual functions.

	I think precisly the same argument applies to, say,
an OO database or any other facility for porting/storing, or
accessing objects. Here enough information is required
to construct objects in the media/user interface.

	Using a classification scheme suggested by David, I will
call the systems requiring external access *foreign* systems,
and the debugger is what I might call a *meta* system.

	In any case the RTTI proposal above will not adequately
support these types of systems, although it might aid in their design.

	That leaves what might be called *domestic* systems,
your common garden program for doing matrix algebra, parsing
a language, etc. These systems include the bulk of operating
systems and other things too.

	It is my belief that DOWNCASTING in such domestic systems
is never necessary. In such systems your program creates
all the objects, therefore, at the point the object is created
it knows the exact type of the objects.

	It is always possible, I contend, to preserve that type
information if it will be required later. If it is thrown away,
the information is deliberately lost specifically to prevent
the object from being accessed with knowledge of its type.

	For example, if I have an abstract class A, and
a subroutine returns a pointer to A, then the subroutine
is deliberately coded so that the true type of the object
cannot be known. That gives me freedom to change the implementation,
knowing for sure nothing can depend on the actual type of the object.
Everthing depends only on the interface specified in the abstract class.

	If that pointer can be cast, whether safely or not,
whether by RTTI or not, to a derived type, then the
implied encapsulation of the OPEN/CLOSED principle is destroyed.
That is, not only is the private implementation of a base class
hidden, but also all the details of all derived types are hidden,
and for the same reason: they are allowed to be changed.

	In the case of downcasting it is much more serious than
accessing implementation details: this does not require
change of the private section, but merely the existence
of several derived classes.

	The correct way to view RTTI then, is not to 
support downcasting, but ANY casting, including and
especially casting from a void* to any class at all.

	As such, there is no reason that I can see that
such casts would be 'interesting' only when there is
by chance a base with a virtual function, since
in that case casting (downcasting) is especially bad style.

	[Never-the-less, if we're going to downcast,
it should be at least *possible* for virtual bases.]

	There is probably a similar argument for
comparison for equality, or, better, comparison
to see if one class is heir to another, however in this
case the use of RTTI might be more essential,
since it facilitates binary operators acting
on two objects of the same type, a poor mans
version of multi-methods or safe covariant
parameters.

	In summary: the proposal above does not go
far enough to support those genuine uses of RTTI in foreign
or meta systems, and attempts to support casting in domestic
systems where it is not only not required, but actually
invalidates the rationale of class based programming,
namely the open/closed principle.


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