In contract inheritance (Was: Re: [Issue 302] New: in/out contract inheritance yet to be implemented)

Bruno Medeiros brunodomedeiros+spam at com.gmail
Fri Aug 25 08:59:27 PDT 2006


d-bugmail at puremagic.com wrote:
> 
> "If a function in a derived class overrides a function in its super class, then
> only one of the in contracts of the function and its base functions must be
> satisified. Overriding functions then becomes a process of loosening the in 
> contracts.
> 
> A function without an in contract means that any values of the function
> parameters are allowed. This implies that if any function in an inheritance
> heirarchy [sic] has no in contract, then in contracts on functions overriding
> it have no useful effect.
> 

Does this makes sense? If in-contracts should be less restrictive than 
their parents (and they should), why allow in-contracts that are not 
less restrictive? Isn't this behavior more adequate:
«In a derived function, *all* in-contracts must be satisfied.
If the first in-contract fails, then it is a programmer error on regards 
to using the function.
If the first in-contract passes, but any parent in-contract fails, then 
there is an error in the function specification itself, since the 
in-contracts are not less restrictive.»

Consider this example:

-----
class Foo {
   void cfunc(int a)
   in {
     assert(a != 42);
   } body {
     writefln("Foo.cfunc: != 42 ", a);
   }

}

class FooBar : Foo {
   override void cfunc(int a)
   in {
     assert(a != 666);
   } body {
     writefln("FooBar.cfunc: != 666 ", a);
   }
}
-----

The in-contract of derived cfunc is not conceptually valid, but DMD 
allows it. It would be nice to detect that at compile-time but that is 
likely not feasible in the general-case, so perhaps we could opt for the 
aforementioned behavior, that would detect this at runtime?


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D



More information about the Digitalmars-d mailing list