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

Subject: Re: [boost] [contract] non-public subcontracting (N1962)
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-06-03 14:24:37

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)...
2) What Eiffel does in this case does not help me much because there
is not really something like protected inheritance in Eiffel...
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".

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.

What do you think?

>From Cline and Lea, "The Behavior of C++ Classes", 1990 -- A++:
<<<
3.3 Inheritance
C++ supports both public and private subclasses. Private subclasses
are used either for partial code reuse or
to express a has-a relationship. With private derivation, no mechanism
is provided for automatic inheritance
either by C++ (inheritance of the public interface) or by A++
(inheritance of behavioral constraints).
Public derivation express the is-a or subtype relation: if VStack is
publically derived from Stack, a
VStack is-a Stack. The implication, lacking currently in C++, is that
a VStack should behave like a
Stack. This is accomplished in A++ by providing VStack with all the
behavioral specications of Stack.
Since the two types may use inherited protected members dierently,
the legal and coherent class-wide
specications are not automatically inherited.
>>>

On Sun, May 30, 2010 at 8:42 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
> Hello all (and N1962 authors especially),
>
> How should subcontracting work for non-public base classes?
>
> I have listed a few examples below. Assume contracts were written for
> all these example classes (invariants) and their functions (pre/post
> conditions).
>
> My questions are:
> A) `c::p()` should subcontract; but what about any of the other member
> functions of `c`, should any of them subcontract also?
> B) Am I missing any other combination of member/inheritance access
> level significant for deciding when to subcontract?
>
>    class bp {
>    public:
>        virtual void p(void) { std::cout << "bp called" << std::endl; }
>    };
>
>    class bf {
>    protected:
>        virtual void f(void) { std::cout << "bg called" << std::endl; }
>    };
>
>    class bg {
>    public:
>        virtual void g(void) { std::cout << "bg called" << std::endl; }
>    };
>
>    class bh {
>    public:
>        virtual void h(void) { std::cout << "bh called" << std::endl; }
>    };
>
>    class c: public bp, public bf, protected bg, private bh {
>    public:
>        // This should subcontract.
>        virtual void p(void) { bp::p(); }
>        // Should any of the following subcontract also?
>        virtual void f(void) { bf::f(); }
>        virtual void g(void) { bg::g(); }
>        virtual void h(void) { bh::h(); }
>        // Am I missing any other relevant combination?
>    };
>
> (I do not think multiple inheritance is relevant for my questions. I
> am using multiple inheritance in this example just so to have only one
> derived class `c` which exercises all the use cases.)
>
> My notes and questions:
> 1) All member functions of `c` are public so they will check their
> pre/post conditions as in `c` and `c` class invariants.
> 2) But shall any `c` member functions also check their base class
> invariants and/or base function pre/post conditions?
> 3) `c::p()` should subcontract `bp::p` pre/post and `bp` inv because
> it is a public function publicly inheriting from a base public
> function.
> ** 4) Maybe `c::f()` should subcontract `bf::f()` pre/post but not
> `bf` invariant... (because `bf::f` is protected thus it does not have
> to check `bf` invariant). **
> ** 5) Should `c::g()` and `c::h()` subcontract given that their
> inheritance is not public? **
>
> Thank you very much.
>
> --
> Lorenzo
>

-- 
Lorenzo