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

In article <92A5AID@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>>	OO database: don't know.
>the database you need to find its complete inheritence tree and load
>it correctly, building the vtables, etc.  I don't know how to do this
>without run time type identification.

	Obviously, you cant.

>
>>	Comms package: not sure.
>
>If it is exchanging objects, then the same arguments apply as for
>an OO database.

	Yes.
>
>>>
>>>Think of stream I/O.  Don't you feel stupid coding an << operator for
>>>each type you want to be able to print?  
>
>>	No. I never use stream IO. I hate it. It is not well
>>designed. Too complicated. Tries to do everything at once.
>>And in Windows, there is no console anyhow.
>>Personally, I use Gets or like for input, and puts for output in
>>textfiles.
>
>>>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.
>
>>	I dont understand. I define string->stream. Once.
>
>>	Now all my objects have a 'print' command that outputs
>>a string. I can print anything. No run-time type info required.
>>Just a virtual function. (And the output can be used in the
>>string package to do other things---much better than stream IO.)
>
>Anybody who follows *your* conventions can then use *your* objects
>in this way.  I assume that you define not only string->stream,
>but also a stream conversion for every single base type.  

	A 'print' function : string print() for each type.

>Then you
>need to find out how many members you have in each class and how to
>access them.....

	I dont understand.
>
>Unfortunately, everybody else has *their* conventions.  How many
>class libraries implement an Object type?  What if they are not
>compatible?  Now do you expect the class libraries you buy to
>follow *your* conventions?  If not, maybe the language specification
>should make this information available to everybody in a uniform
>way.
>

	For debugging purposes, a print function would be great,
but NOT to streams. I use Windows, there are NO streams
(well, there are: disk files I personally open).

	So you see immediately there is a problem here.


For the types of application you have mentioned,
where full knowledge of the structure of a class is required
(in effect, the source), C++ is clearly inadequate.

To REALLY do what you want, you need a proper, fullscale,
reflexive system.

What concerns me is that, for example, if you can say
get a description of the details of a class,
then you can 'cheat' the system, and fiddle with details
that were supposed to be hidden.

Of course, in an OO database you might want to do exactly that:
how else can the user define a new object?

But then you are writting in C++ a new system, and an interpreter
aided by the C++ run-time system: I don't know what you
call this class of programs, but for this class of programs
you need run-time support---LOTS of it. No argument.

It is just not the sort of program I think of as a typical
use for C++, principally because it is a static system
designed for writting type-safe programs,
and NOT a system designed for implementing systems
compatible with itself.

Why not use Smalltalk or Lisp: they already have the 
properties you need. C++ with only run-time support
added will STILL be almost unworkable for a system
like an OO database that really requires reflexivity.

Anyhow, I have always accepted this limitation of C++,
but if you really think it is feasible to make
C++ reflexive, I will re-think. I would really
like that, I just didn't think it was possible.


-- 
;----------------------------------------------------------------------
        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++,comp.std.c++