From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: run-time type checking)
Date: 18 Aug 92 16:12:46 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: In article <713823917snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
: >
: >In article <4820@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
: >
: >> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: >> :
: >> :There are other ways than tagged pointers to make downcasting
: >> :sound. One might be to declare the derived classes that you want
: >> :to downcast to in the base class FROM which you want to downcast:
: >> :	class Base { //....
: >> :		operator Derived1*() =0;
: >> :		operator Derived2*() =0;
: >> :	};
: >> :Now what does this do? Well, it preserved th open/closed principle
: >> :and encapsulation and the explicit interfaces principle.
: >> 
: >> What if someone using your classes decides to add a Derived3 class
: >> to which downcasting should be possible?  He must modify your
: >> class Base, for which he may not have source code.
: >> 
: >> Does not (help) preserve the open/closed principle at all, IMHO.
: >Perhaps I misunderstand the meaning of the "open/closed principle", but I 
: >understood that it implies that every operation which can be applied to an
: >object through a reference or pointer to a Base class should be visible in 
: >the Base class declaration. 
: 
: 	Actually, Meyer calls that the Explicit Interfaces Principle.

****	From Meyer (p21) [Explicit interfaces]:

	"Whenever two modules A and B communicate, this must be
	 obvious from the text of A or B or both".

	You take this to mean "...obvious from the interface of
	A or B", which is not what the author said, but perhaps what
	he meant.  Fine.
	
: A module is closed if it is available for use (finished, compiled,
: stored in a library). A module is open if it can be extended
: (new fields added, new functions defined, old functions restricted)
: The open/closed principle states a module should be both open and
: closed. The mechanism of inheritance and virtual functions, that is,
: having classes as modules, satifies these criteria.

****	Right.

	I would like to argue that your initial suggestion means that you
	will have to go back and extend the interface of a base class,
	to support operations in a new derived class.  If this is
	indeed an option for you, why don't you instead add the new
	operations as virtual functions of the base class?  The base
	class interface was after all not really closed, was it?

	Even Eiffel has "reverse assignments" to do safe
	downcasting (kind of supports interface openness).

: 	By making the ability to downcast Explicit in the interface
: of the base class, the closure of the base now depends on the listed
: derived classes too, so it is then open (excepting the named derived classes).

****	I agree that this is a good thing, _if you can do it_. Base
	classes that will be extended by other programmers cannot
	in general list all future derived classes.

: 	Another method is to use tagged pointers. ALL these methods
: suffer from lack of extensibility that downcasting doesn't. Thats
: because there is only ONE method of extensibility that is sound,
: and we already have it. Polymorphism. Virtual functions.

****	Sound or not, when polymorphism does not suffice, you
	have to rely on something else, right?

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
--------------------------------------------------------------------------