From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: Covariant Types in Derived Classes
Organization: netmbx, Berlin, Germany
Date: Thu, 23 Jul 1992 07:36:29 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>In article <92A5AID@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
>>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

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

>	I dont understand.

If I want a generic print function that can handle all types as though they
were basic types, then this print function must know the location and type
of each member, and also the name if the function is to be particularly
useful.

>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.

But if Windows provides you with general tools like the ones
I am describing then there is no such problem.  To do so they
need the run time type information.

>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.

Yes and no.  All of the applications I have mentioned can get by
with run time type identification.  A full scale reflective system
certainly has its advantages, but 

>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.

You can do this with pointers also.  What concerns me is that
people are already writing precompilers for C++ simply because
they need this run time identification for such bread and butter
applications as object oriented databases.  That is OK if only
one of the tools you use needs a precompiler, but when you need
two tools which each need a precompiler this can lead to problems.

Similarly, if every tool you use defines an Object type from which
all of your classes must be derived then you start having problems
when you want to use several tools simultaneously.

>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.

No, I am not aware of any OO database which uses an interpreter
to build class methods.  Typically, a standard C++ constructor
is used to create a new object.  But the database maintains a
class dictionary to keep track of data members.

>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.

Object oriented databases are a very typical tool for use with
C++, as are user interface tools, CASE tools, communications
packages, etc.   The C++ community is better off if these tools
are easily available.  You do not need a fully reflective system
to provide these tools, and you would not need precompilers if
the run time identification were available.

>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.

Type safe systems are essential.  Neither Smalltalk nor Lisp are
type safe.  At ECOOP this year I was struck by the extent to which
all sides agreed that both type safety and dynamic binding are
important.  Maybe there will be a language in the future which
is fully reflective and is as good as C++ for large scale systems
development.  For now we are focussing on providing tools for
existing languages.  C++ is wildly popular, and is the best market
for our tools.  It is also a good language, with a few minor wrinkles
here and there...



Jonathan

===========================================================================

Jonathan Robie		jrobie@netmbx.UUCP
Arnold-Zweig-Str. 44	jrobie@netmbx.in-berlin.de
O-1100 Berlin		
Deutschland		Phone:  +37 (2) 472 04 19  (Home, East Berlin)
				+49 (30) 342 30 66 (Work, West Berlin)



-- 
Jonathan

===========================================================================

Xref: sparky comp.lang.c++:11423 comp.lang.c:11530