home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.lang.c++:11437 comp.std.c++:929
- Newsgroups: comp.lang.c++,comp.std.c++
- Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
- From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
- Subject: Re: Language extensions for run-time type identification
- Message-ID: <1992Jul23.174158.13819@ucc.su.OZ.AU>
- Sender: news@ucc.su.OZ.AU
- Nntp-Posting-Host: extro.ucc.su.oz.au
- Organization: MAXTAL P/L C/- University Computing Centre, Sydney
- References: <TMB.92Jul20182052@arolla.idiap.ch> <1992Jul20.220534.1365@cadsun.corp.mot.com> <1992Jul21.094204.20100@mole-end>
- Date: Thu, 23 Jul 1992 17:41:58 GMT
- Lines: 121
-
- In article <1992Jul21.094204.20100@mole-end> mat@mole-end writes:
- >In article <1992Jul20.220534.1365@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
- >
- >> I sencond this. As I already said, run time type checking of classes
- >> only with virtual functions is not a serious solution.
- >
- >> David Shang
- >
- >Let's be sure that we are talking about the same thing, then I'll ask you
- >to refute an assumption underlying the current proposal.
- >
- >The current proposal would allow a number of things, including at least
- >checked downcasting and some kind of comparison-for-equality of the exact
- >type of objects.
- >
- >There are many bad uses for these facilities, but there are also good
- >uses, or so it is believed.
- >
- >The assumption underlying the decision to include only classes with
- >virtual functions is that a class that has no polymorphic behavior
- >whatsoever (not even a virtual destructor) cannot be used in any way
- >that is both safe and interesting even with the proposed runtime type
- >support. Can you refute this assumption?
- >--
- Before I start: I'm not against adding RTTI. But allow
- me to play 'devils advocate' as hard as I can. :-) Convince
- me that downcasting is a good thing, for example.
-
- What is the basis for this assumption?
-
- On the contrary, polymorphism BY NATURE, provides the
- correct mechanism for accessing the exact object, it is
- especially in this case that casting is not only dangerous
- but unnecessary.
-
- In the discussion about RTTI I have participated in with David,
- we agree on at least one thing: RTTI is required for writing Debugger.
- Clearly a debugger needs access to ALL the type information,
- so mere safe downcasting and comparison for equality would not be
- adequate, nor a restriction to classes with virtual functions.
-
- I think precisly the same argument applies to, say,
- an OO database or any other facility for porting/storing, or
- accessing objects. Here enough information is required
- to construct objects in the media/user interface.
-
- Using a classification scheme suggested by David, I will
- call the systems requiring external access *foreign* systems,
- and the debugger is what I might call a *meta* system.
-
- In any case the RTTI proposal above will not adequately
- support these types of systems, although it might aid in their design.
-
- That leaves what might be called *domestic* systems,
- your common garden program for doing matrix algebra, parsing
- a language, etc. These systems include the bulk of operating
- systems and other things too.
-
- It is my belief that DOWNCASTING in such domestic systems
- is never necessary. In such systems your program creates
- all the objects, therefore, at the point the object is created
- it knows the exact type of the objects.
-
- It is always possible, I contend, to preserve that type
- information if it will be required later. If it is thrown away,
- the information is deliberately lost specifically to prevent
- the object from being accessed with knowledge of its type.
-
- For example, if I have an abstract class A, and
- a subroutine returns a pointer to A, then the subroutine
- is deliberately coded so that the true type of the object
- cannot be known. That gives me freedom to change the implementation,
- knowing for sure nothing can depend on the actual type of the object.
- Everthing depends only on the interface specified in the abstract class.
-
- If that pointer can be cast, whether safely or not,
- whether by RTTI or not, to a derived type, then the
- implied encapsulation of the OPEN/CLOSED principle is destroyed.
- That is, not only is the private implementation of a base class
- hidden, but also all the details of all derived types are hidden,
- and for the same reason: they are allowed to be changed.
-
- In the case of downcasting it is much more serious than
- accessing implementation details: this does not require
- change of the private section, but merely the existence
- of several derived classes.
-
- The correct way to view RTTI then, is not to
- support downcasting, but ANY casting, including and
- especially casting from a void* to any class at all.
-
- As such, there is no reason that I can see that
- such casts would be 'interesting' only when there is
- by chance a base with a virtual function, since
- in that case casting (downcasting) is especially bad style.
-
- [Never-the-less, if we're going to downcast,
- it should be at least *possible* for virtual bases.]
-
- There is probably a similar argument for
- comparison for equality, or, better, comparison
- to see if one class is heir to another, however in this
- case the use of RTTI might be more essential,
- since it facilitates binary operators acting
- on two objects of the same type, a poor mans
- version of multi-methods or safe covariant
- parameters.
-
- In summary: the proposal above does not go
- far enough to support those genuine uses of RTTI in foreign
- or meta systems, and attempts to support casting in domestic
- systems where it is not only not required, but actually
- invalidates the rationale of class based programming,
- namely the open/closed principle.
-
-
- --
- ;----------------------------------------------------------------------
- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
- Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
- ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
-