August 16, 2001
Hi,

I read the section on contracts and I think I noticed a problem with regards to inheritance:

"
In, Out and Inheritance
If a function in a derived class overrides a function in its super class, then the in contracts must be satisified for each base function. Overriding functions then becomes a process of tightening the in contracts.
Conversely, only one of the out contracts needs to be satisified, so overriding functions becomes a processes of loosening the out contracts.
"

I believe that is backwards, in contracts should be loosened (or the same) and out contracts should be tightened (or the same). Allow me to quote from Meyer's "Object-Oriented Software Contruction" Section 16.1:

"
Assertion Redeclaration Rule (1)
 A routine redeclararation may only replace the original precondition by one equal or weaker, and the original postcondition by one equal or stronger.
"

Dan

August 16, 2001
Good catch. I think I did get that inverted in the doc. Thanks! -Walter

"Dan" <zakaib@mda.ca> wrote in message news:3B7C1976.80108@mda.ca...
> Hi,
>
> I read the section on contracts and I think I noticed a problem with regards to inheritance:
>
> "
> In, Out and Inheritance
> If a function in a derived class overrides a function in its super
> class, then the in contracts must be satisified for each base function.
> Overriding functions then becomes a process of tightening the in
contracts.
> Conversely, only one of the out contracts needs to be satisified, so overriding functions becomes a processes of loosening the out contracts. "
>
> I believe that is backwards, in contracts should be loosened (or the same) and out contracts should be tightened (or the same). Allow me to quote from Meyer's "Object-Oriented Software Contruction" Section 16.1:
>
> "
> Assertion Redeclaration Rule (1)
>   A routine redeclararation may only replace the original precondition
> by one equal or weaker, and the original postcondition by one equal or
> stronger.
> "
>
> Dan
>