Re: [boost] [contract] non-public subcontracting (N1962)

Subject: Re: [boost] [contract] non-public subcontracting (N1962)
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-06-14 15:34:07

Sorry for the late reply but I just realized that my original reply of
Jun 9 bounced back...

On Tue, Jun 8, 2010 at 4:28 PM, Thorsten Ottosen <nesotto_at_[hidden]> wrote:
> Lorenzo Caminiti skrev:
>>
>> Hello everyone,
>>
>> Allow me to reiterate my question:
>>
>> On Sun, May 30, 2010 at 8:42 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>
>> wrote:
>>>
>>> How should subcontracting work for non-public base classes?
>>
>> (See details in my previous email below.)
>>
>> 1) I have looked at N1962 (and its previous revisions) but I could not
>> see how the proposal addresses non-public inheritance. I might be
>> missing something (given that the N1962 is rather detailed)...
>
> Well, since it has no special case for this, the same rules apply
> for all types of virtual functions.

Does "the same rules" mean that, regardless of the inheritance access
levels of the base classes:
1) Preconditions are checked in OR with the ones of all base functions.
2) Postconditions are checked in AND with the ones of all base functions.
3) Class invariants are checked in AND but only with base class
invariants for of public base functions.

I want to make sure I understand especially 3) clearly in the context of deep
inheritance level (not multiple inheritance). Assume contracts were
written for all these classes and member functions:

   class a {
   // Don't check a:: invariants.
   protected:  virtual void f(void) {}
   };

   class b: public a {
   // Check b:: invariants (but not a:: invariants).
   public:     virtual void f(void) {}
   };

   class c: protected b {
   // Check b:: invariants (but not c:: or a:: invariants).
   protected:  virtual void f(void) {}
   };

   class d: protected c {
   // Check d:: and b:: invariants (but not c:: or a:: invariants).
   public:     virtual void f(void) {}
   };

A call to d::f() will end up checking d:: and b:: class invariants but
not c:: or a:: class invariants -- correct?

>> 2) What Eiffel does in this case does not help me much because there
>> is not really something like protected inheritance in Eiffel...
>
> You can override a private virtual function, so why should the rules
> be special for them?

Yes, you can override a private virtual function and do so even if the base
class is private (I have written a simple example to double check
that). Therefore, "no special rule" is a reasonable option.

>> 3) I looked at an old Contract Programming proposal for C++ called
>> "A++". This proposal addresses this issue as quoted below but this is
>> a very old proposal from 1990 so I cannot consider it the "state of
>> the art".
>
> I had not seen this before. Thanks.

This was cited in "Design and Evolution of C++". If you are
interested, you can find A++ papers at:
http://gee.cs.oswego.edu/dl/papers/A++-sooppa.ps (the page order is reversed...)
http://gee.cs.oswego.edu/dl/papers/A++-C++AtWork.ps

>> BTW, I am asking because I need to decide how to implement
>> subcontracting for protected and private inheritance in
>> Boost.Contract. One option could be (essentially following A++):
>> a) Preconditions, postconditions, and invariants are all subcontracted
>> for public inheritance.
>> b) Only preconditions and postconditions (but no invariants) are
>> subcontracted for protected inheritance.
>> c) Nothing is subcontracted for private inheritance.
>> This should still satisfy Liskov substitution principle.
>
> I guess you can do whatever is the easiest. I'm not up to date with
> the rules, but is it not so that I can override a priviate virtual function
> of a private base class? If so, I see no reason to make special
> rules forbidding subcontracting although it is somewhat unclear what
> the point with a such a piece of code would be.

I think, the subcontracting rules of A++ make sense but they are a bit
more complex for users to understand than N1962 simpler rule "there is no
special rule". Furthermore, I have never experienced any real
benefit/need for implementing something like A++ subcontracting rules.
Therefore, I am happy to implement Boost.Contract as specified by
N1962 with "no special subcontracting rule based on the base class
inheritance access level". (However, I might have more observations on
the topic once I start implementing this.)

--
Lorenzo