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

nikki@trmphrst.demon.co.uk (Nikki Locke) writes:

>In article <1MH5C0K@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:

>> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
>> 
>> Why not allow default display using exactly the same information used by
>> the debugger?
>So, as I understand it, you want some kind of RTTI which enables you to 
>determine not only the type (class) of any object, but also details of 
>every public and private variable and implementation details within the 
>class. Can this really be true ? If it is, you don't want C++ :-) I must 
>be mis-interpreting, surely.

Maybe I am corrupted by working on object oriented database systems which
need to store and retrieve objects without forcing the user to tell us what
the objects are.  We do in fact need the kind of info you describe.  There
are other systems which also need this kind of info, as I have pointed out
in previous messages.  

You are right that a C++ user-interface system should observe encapsulation.
We don't want everybody editing all the variables in the program.  On the
other hand, we may well want to display private or protected data members.
Since the programmer can easily write code to allow these members to be
edited or displayed, is it any different to provide a general purpose tool
which allows the programmer to interactively select and rearrange the fields
that should be edited or displayed?

I don't really know what the right design for such a tool would be.  It
certainly raises some interesting questions!

>> The alternative is to require a programming strategy like this:
>> 
>> 	1.  Design the class you need
>> 	2.  Write code to print objects of this class
>> 	3.  Write code to store objects of this class in a database
>> 	4.  Write code to display objects of this class
>> 	5.  Write code to input and edit objects of this class
>> 
>> We all agree that reliable code is our goal.  General purpose tools
>> which can largely automate steps 2-5 will greatly reduce the amount
>> of code that needs to be written for each class.
>
>Fine - but these general purpose tools should be code generators, not 
>sufficient RTTI to enable any hack programmer to totally subvert the type 
>system, encapsulation, data hiding and just about everything else that's 
>good about OOPL's.

Our object oriented database, POET, generates code to make this RTTI
available in a way that is not documented for our users.  We need a
precompiler to extract this RTTI from the user's headers.  The
programmer includes our generated headers in the program, and compiles
and links our generated code to the rest of the executable.  This is a
workable system, *but*

What happens when you buy 4 different code generators to handle steps
2-5?  Does this mean you need 4 different precompilers and a compiler?
Will each manufacturer provide different keywords to tell them
for which classes they should generate code?  Might these keywords be
unintelligible to the other systems?  Which generators will have to
work on the output of the other generators?  Could there be name space
conflicts?  How much code will be generated?  Might this affect the size
of your executables?

All of the information these libraries need is produced by the compiler
and then thrown away (although it is generally made available to the 
compiler-manufacturers' own debugger).  Why make every library that
needs it generate it again?  It sure would be nice to be able to write
a good database system without writing a compiler first...the same holds
for the other tools I describe.  Ideally, one compiler should be enough!

Your concern for protecting "the type system, encapsulation, data hiding 
and just about everything else that's good about OOPL's" is both valid
and important.  Obviously, you can break all of these using pointers,
casts, and other dangerously powerful features of the language.  Extended
run time type information is for general purpose tools which manage
generic objects--this is a kind of programming which should not be used
for general purpose application programming.  In C++ the type system,
encapsulation, data hiding, etc. are protected only when you follow
certain conventions.  Do you want us to eliminate pointers and casts?



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

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