From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: run-time type checking)
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 21 Aug 1992 00:03:59 GMT

In article <4846@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>****	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.

	Actually, this distinction is important. Note eiffel does not
have separate interfaces. And in C++ a subroutine can USE a type
not mentioned in its interface.
>	
>: 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 you want to use derived classes outside their design goal
of implementing 'isA' relations.

>	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?

	That would be equivalent more or less (perhaps more work
	to add more member names as virtuals).
>
>	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.

	Why would they have to list ANY? When you derive from a base
class you should stick to the interface of the base class if you
are going to use the derived class AS A base. If you are just
using inheritance as a convenient form of composition, you should
recognize that fact, and not expect polymorphic behaviour
from unrelated types.

>
>: 	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?
>
	Yes. But we need a solution that does not compromise
polymorphism. Adding new interfaces to a class is composition.
Restricting the base class is polymorphism. They are 
diametrically opposed mechanisms that can both be done in C++
by inheritance. Unfortunately perhaps they can both be
done simultaneously and legitimately, but I think it is necessary
to separate the two conceptually. Allowing unconstrained
downcasting might fail to do that.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------