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: Tue, 21 Jul 1992 15:03:32 GMT

In article <1992Jul20.141712.4622@cadsun.corp.mot.com> shang@corp.mot.com writes:
>In article <1992Jul17.154635.27331@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU  
>(John MAX Skaller) writes:
>> 	Certainly there are het aggregates out there, say
>> Windows 3.0 window lists. But the can be converted to C++
>> objects without loss of type info: they don't have to
>> be collected in the same form as they are presented to
>> you.
>>
>
>You need, at least, a pre-compiler to analize the type system and gather the  
>information for this case. 

	If you try to use C++ in an evironment where the system
must be dynamically extended with completely new types, you
will certainly need run-time type info. In fact, you had better
be able to incrementally compile and dynamically link as well.
So you need a proper reflexive system.

	C++ is way off being able to do that, even if it had
run-time type-info.

	Any how for this sort of facility:: one where you
try to use C++ for something way outside its original purpose,
and way outside the boundaries of any statically compiled
system, well, yes, run-time type info is needed, and much
much more.

	But you will note: we're not talking about mere
downcasting here---*that* was the original issue.
Here you're talking about dynamism---dynamic typing,
dynamic compilation, dynamic loading, etc etc---
all those things that Lisp and Stalk already do,
I might add.


>Let me give you some more examples. (1) OO operating  
>systems written in C++: most systems must have their own pre-compiler that  
>gathers the type information in order to provide a high level OO user  
>interface. (2) OO database systems: they must have their own languages, at  
>least a pre-compiler if they chose C++ as their master language, and most of  
>the work for the pre-compiler is to gather the type information. 

	Here the precompiler is a nasty compromise.  A proper
reflexive (self-extensible) system is what is really needed.

>And see  
>another good example that Jonathan Robie gives us:
>
>In article <5W0422J@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie)  
>writes:
>> Think of stream I/O.  Don't you feel stupid coding an << operator for
>> each type you want to be able to print?  An intelligent stream facility
>> would be able to print any object with a sensible default format which
>> could optionally include the name and type of each field.  Try to code
>> this without run time information.  Since the I/O stream is coded first
>> and can impose no restrictions on user objects I do not know of any way
>> to solve this without adding my own precompiler.
>> 

	Well, in this case there is no need at all for dynamic typing,
a mere virtual function returning a string does the job just fine.
>
>In the same article <1992Jul17.154635.27331@ucc.su.OZ.AU>  
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>> Lets take feeding of animals. You must spec. the problem better.
>> Does each animal know the types (finite list) of food they eat?
>> E.g, you have list of base classes for each animal.
>> 
>> Now you have list of animals and list of foods, and feed each
>> available food to animal until food is eaten. Is this
>> what you want?
>> 
>>
>
>No, never. What I want is a spec.-- a spec. of a food type which is dependent  
>on the animal type, and such dependency can be checked statically at compile  
>time.

	Sure, but I don't understand *exactly* what you mean.
I think you will have trouble formulating the problem.
The reason I say this is that in general the solution
requires multiple dispatch, in other words, a matrix of
animal x food entries.

	Can you *reduce* the problem to less than a matrix?

>
>David Shang
>
>
>
> 
>> -- 
>> ;----------------------------------------------------------------------
>>         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
>> 	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
>> ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------


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