From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: ***
X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID,
	RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME,T_FILL_THIS_FORM_SHORT
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,b87849933931bc93
X-Google-Attributes: gidfac41,public
X-Google-Thread: 109fba,b87849933931bc93
X-Google-Attributes: gid109fba,public
X-Google-Thread: 103376,b87849933931bc93
X-Google-Attributes: gid103376,public
X-Google-Thread: f43e6,b87849933931bc93
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 1108a1,b87849933931bc93
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 114809,b87849933931bc93
X-Google-Attributes: gid114809,public
From: "Risto Lankinen" <rlankine@us.oracle.com>
Subject: Re: What is wrong with OO ?
Date: 1997/01/16
Message-ID: <01bc03f5$b3af1d00$ba1e1990@ap352pc.us.oracle.com>#1/1
X-Deja-AN: 210310232
references: <JSA.97Jan1181506@alexandria>
 <01bbd23a$5b667cc0$LocalHost@christophe-leph> <E440xD.Lu0@ecf.toronto.edu>
 <01bc03db$2de477c0$ba1e1990@ap352pc.us.oracle.com>
 <E448IK.4qI@ecf.toronto.edu>
content-type: text/plain; charset=ISO-8859-1
organization: Oracle Corporation
mime-version: 1.0
newsgroups: 
 comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng
Date: 1997-01-16T00:00:00+00:00
List-Id: <comp.lang.ada>


Hi!

Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
<E448IK.4qI@ecf.toronto.edu>...
> In article <01bc03db$2de477c0$ba1e1990@ap352pc.us.oracle.com>,
> 
>   I was not aware that private virtual functions existed.  Can a
descendant
> class override this function even though it does not have access to it?

Sure can.  The descendant cannot, however, *call* the base version.
Also, the descendant is responsible for using the proper protection
for its own version: 'Derived::Function_imp' can be made public if
that is desired.

> >Note that *IF* the Java keyword 'final' was also in C++ (in Java
[blah blah blah]
> >can override...
> 
>   Woah, sorry, you lost me here.  Do you have an example of what you're
> thinking of?

Here is (in a hypothetical language that looks like C++ but has a
keyword 'final' to declare a class that cannot be derived from; or
a class method that cannot be overridden by a method in a derived
class):

---------------------------------------------
class Bottom
{
public:
   virtual void do()
   {
      // do what bottom objects do
   }
};

class Middle : public Bottom
{
private:
   virtual void do_imp()
   {
      // do what middle objects do
   }

public:
   final void do() // <<<<<<<<<<<< see below (#)
   {
      // middle preconditions
      do_imp();
      // middle postconditions
   }
};

class Top
{
private:
   virtual void do_imp()
   {
      // do what top objects do
   }
};
---------------------------------------------

Note (#):
In original example this function was a non-virtual.  Here, it is
an inherited virtual.  Alas, declaring it 'final' prevents it from
being overridden by any derived class.

If 'Middle::do()' was non-final, the programmer of class 'Top' may
be tempted to override that instead of 'do_imp()', shortcutting the
integrity maintenance performed by 'Middle::do()'.

Furthermore, if class 'Top' has a reason to make its postcondition
more strict, it can declare 'do_imp()' as 'final', and have its own
implementation call a private virtual 'do_imp_imp()'.  Here is such
modified definition of class 'Top' (note how it looks like 'Middle'
in previous example):

---------------------------------------------
class Top
{
private:
   virtual do_imp_imp()
   {
      // do what top objects do
   }

   final void do_imp()
   {
      // top preconditions
      do_imp_imp();
      // top postconditions
   }
};
---------------------------------------------

When a 'Top' object is passed to a function as a 'Base' pointer
or a reference, it performs the following calls, when 'do()' is
called:

   do() [Middle]
    + // middle preconditions
    + do_imp() [Top]
    |  + // top preconditions
    |  + do_imp_imp() [Top]
    |  |  + // do what top objects do <<<<<<<< see below (@)
    |  + // top postconditions
    + // middle postconditions

Note (@):
Because 'Middle::do()' and 'Top::do_imp()' would be final, the
only function that could be overridden is do_imp_imp().  Note,
that doing so cannot by-pass any of the integrity maintenance
that are performed by some of its base classes.

terv: Risto L.