From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Novice? question: Designing for mul
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 29 Jul 1992 17:07:42 GMT

In article <rmartin.712271000@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>maxtal@extro.ucc.su.OZ.AU writes:
>
>
>|In article <rmartin.711299360@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>
>Oh it makes sense to do this, maybe.  But the ARM leaves the question
>open.  

	Yes. It needs to be fixed.

>
>An abstract class is a class with a pure virtual function, either
>specified or inherited.  If you are inheriting from two classes, one
>of which has a pure virtual, and the other has the same virtual
>function, but impure, should be base be abstract or not?  

	What do you mean by 'has' a function? Having
an explicit declaration is quite different from inheriting.

	The real culprit is the wording of the section dealing
with inheritance of pure virtuals.

	It says that inheriting a pure virtual as a pure virtual
is a *safe* default. That was a major bungle. It is not
a safe default, it is absolutely mandatory that pure virtuals
do NOT need to be redeclared.

>Is the pure
>virtual inherited, or are impure virtuals inherited preferentially to
>pure virtuals.  

	No: the one used is the dominant one. End of story.
There is no ambiguity in which function is called. (Unless there
is no dominant one).

	How can you possibly conceive that a class 'has' a function
which cannot be called?
>
>I am leaning with your interpretation, that the impure should be
>inherited preferentially, and that the class should not be abstract.

	No, this is not the correct interpretation. It is
irrelevant whether a function is pure or not. The function which
is called is determined by the name dominance rule. If that
function is pure, the class is abstract. If no such functions
are pure the class is concrete.

>But I don't think the issue is as clear cut as you claim.  For
>example, I could pose the following argument:
>
>In any case where a pure virtual and an impure virtual can be
>inherited through separate branches of the DAG, the pure virtual
>should have preference since it makes an unambiguous statement that
>the function should be overridden in the *derived* class.  Since
>inheriting the impure is not the same as overriding, it should not be
>inherited.

	It is irrelevant.
>
>Maybe you don't agree with that argument.  I am not sure I do either.
>But it does demonstrate that the issue could be debated.

	No. The function used is determined by the name dominance
rule. There is NO ambiguity here. The ambiguity is is the
wording of the definition of abstract class. It says 
'has' a function. You can argue that 'has' might mean.
>
>
>
>|-- 
>|;----------------------------------------------------------------------
>|        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
>|	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
>|;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
>--
>+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
>| rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
>|     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
>+----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |


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