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