home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!darwin.sura.net!mips!mips!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
- From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
- Subject: Re: mating dogs and cats (Re: run-time type checking)
- Message-ID: <1992Jul29.173149.821@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: <1992Jul22.022218.1115@cadsun.corp.mot.com> <1992Jul23.154254.5306@ucc.su.OZ.AU> <TMB.92Jul28121957@arolla.idiap.ch>
- Date: Wed, 29 Jul 1992 17:31:49 GMT
- Lines: 62
-
- In article <TMB.92Jul28121957@arolla.idiap.ch> tmb@idiap.ch writes:
- >In article <1992Jul23.154254.5306@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
- >
- > The problem is why you proposed 'thisclass' and is a real problem.
- > It is a problem for which RTTI is the wrong solution,
- > but never-the-less is the best we will get for a while.
- > We really need multiple dispatch.
- >
- > class Animal {
- > int mate(Animal&);
- > };
- > class Dog : Animal {
- > int mate (Animal&);
- > };
- >
- > We REALLY want Dog::mate(Dog&), but we cant have it.
- >
- >I don't see the problem.
- >
- >class Animal {
- > virtual int mate(Animal &) = 0;
- > virtual int mate_dog(Animal &other) {error("not a dog");}
- > virtual int mate_cat(Animal &other) {error("not a cat");}
- >};
-
- You clearly DONT see the problem. You do not understand the
- open/closed principle. The problem with the definition of Animal
- above is that it is not OPEN. you cant make the mechanism work
- if you add RAT without modifying Animal. That is a violation
- of the open/closed principle.
-
- A base class must be CLOSED
- so that it can be compiled and the inteface frozen, even the
- source code thrown away for the definitions. Algorithms
- defined for the base class can be written, and compiled,
- and type checked WITHOUT knowledge of the derived classes.
- The closure of the base should guarrantee that.
- (Which is why I am suspicious of downcasting).
-
- A base class must be OPEN to extension by derivation.
- Arbitrary extension. AND in particular 'arbitrary'
- means not only that you can add any new derived classes
- you choose, but also that you can OMIT any you choose.
- Downasting voids that guarrantee.
-
- Virtual functions achieve this. They are closed in the base.
- They are still open to overriding in the derived class.
-
- Unconstrained Downcasting voids both the open-ness and the closedness.
- Without the open closed principle assured by the language,
- polymorphism is flawed and the system is unsound.
-
- Indeed CASTING of any kind (changing the type of something)
- is unsound. Upcasting is sound because a derived
- 'isA' base, so you are not changing the type,
- just forgetting some details.
-
- --
- ;----------------------------------------------------------------------
- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
- Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
- ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
-