From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 24 Jul 1992 19:22:07 GMT

In article <1992Jul24.143359.3602@advtech.uswest.com> glw@io.uswest.com (Glenn Williams) writes:
>>(John MAX Skaller) writes:
>>
>>	Given the need to do downcasting, to do it safely run-time
>>type information is required. But I am arguing it is not necessary
>>to downcast. So the question of needing run-time type info to
>>do it doesn't arise.
>>
>>We design our systems properly in the first place, and then the need
>>to downcast never arises, when our thoughts wander in that 
>>direction one can be sure we are not thinking virtuously,
>>and perhaps the design itself is flawed.
>
>Ok, let's have an example of a properly designed system. 

	I can of course give any number of systems not using
downcasting --- LOTS of code I have written for example.

	But that wont PROVE anything. You have to give me
an example of a system that uses downcasting and then I'll
show how to write it without downcasting.

	Please restrict examples to domestic systems, since
I already agree all bets are off for foreign systems and
also for introspective ones like, say, debuggers, OODBMS,
etc.

	Lets agree for example to restrict ourselves to
text input and output and no disk storage. Lets agree
that the program must handle a fixed number of types.
And that it reads text in, does some calculations,
and then prints the answers.

	Such a program creates ALL the objects, manipulates
them, and then it terminates.

>
>>	Inother words, in a *domestic* system, any apparent 
>>need for downcasting should be used as an indicator of flawed design.
>>
> 
>What is the basis for your conclusions?

	There are two reasons.

	1) Its NEVER necessary. Because you CREATED all the objects
	in the first place, you know their types at that point in
	time, agreed?

	So if you want to find out the type of an object, you have
	forgotten something you once knew---and that is a design
	flaw if you needed to know the type.

	2) The second reason is that downcasting---indeed ANY casting
	and not downcasting in particular---cheats the type system
	by giving you access to hidden implementation details.

	I dont want to write a book on why one should want to hide
	implementation details :-) I assume you know about this
	and agree it is proper.

	But the derived type of a base IS PRECISELY implementation
	details of the base class.

	Polymorphism, though virtual functions, provides the
	CORRECT and safe way to access the particular
	implementation of an object---by virtual function calls.

	So ESPECIALLY in the case of pointers to bases,
	casting is unnecessary and bad. There is already
	a proper way to access the derived class.

	If you cant figure how to do what you want via the base
	class---it is a design flaw.
>
>You have stated all this before, and every time you do, you fail to provide
>any examples of how you would design without downcasting. 
>
>So, as I asked for earlier, let's have an example of a properly
>designed system.
>

	Sure. But you have to tell me what problem you want to solve,
else I'll just give you a copy of my, um lets see, matrix clas,
or perhaps my network emulator, or perhaps my chemical plant
Quantative Risk Analysis Program.

	Believe me, in the QRA program I was tempted to downcast.
Apparently some problems couldn't be solved without it. But,
because it used dynamic linkage, I COULDN'T cheat by downcasting,
even if I wanted to, since athe main program had no idea
what derived classes would be used (they are loaded dynamically
under user control). By not using downcasting I am
GUARRANTEED that ANY proper implementation of the
various base classes could be used.

	As soon as I put even one downcast in, then that
module MUST be loaded. And that defeats the design spec
of having ALL the components dynamically linkable.

	QRA models hazards at chemical plants. The objects
include hazardous chemicals, and various types of fixtures
like tanks and pipes. The fixtures are 'drawn' on a map
using the mouse.

	Chemicals are put in the containers, and various
leaks occur, fires start, toxic materials are dispersed.
The accumulated affects over a million years are
then plotted on a map, and the results sold to
the chemical companies (for safety reasons, or because
governments require Environmental Impact Statements
to be done).

	The hardest part of this system was to have a few
abstractions representing 'container', 'chemical',
and 'phenomena' (leak, fire, etc).

	The actual numerical modelling of fires was easy,
because the client supplied the algorithm :-)
-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------