NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/cplus/12684

Text File | 1992-08-20 | 3.9 KB | 94 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: run-time type checking)
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]>
Date: Fri, 21 Aug 1992 00:03:59 GMT
Lines: 81

In article <[e-mail]> [e-mail] (Johan Bengtsson) writes:
>[e-mail] (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,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------