home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!netmbx!jrobie
- 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
- Message-ID: <P6C5COF@netmbx.netmbx.de>
- References: <5W0422J@netmbx.netmbx.de> <1992Jul20.154835.9269@ucc.su.OZ.AU> <92A5AID@netmbx.netmbx.de> <1992Jul21.183932.1541@ucc.su.OZ.AU>
- Lines: 110
-
- 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
-
- ===========================================================================
-
-