Michael G Schwern:
>
> I've been mucking about a bit more with this whole interface thing.
>
> So if we make method signatures only enforced on subclasses
> if the parent class or method has the interface property...
>
> ....except private methods, obviously.
>
> And if we make pre/post conditions and class invariants
> always enforced...
no.
post-conditions and invariants are always enforced, but pre-conditions are
different. A derived interface can loosen input constraints... so it must be
able to either satisfy all inherited pre-conditions _or_ its own
pre-conditions.
> ....shouldn't we have private invariants and conditions?
no.
I should inject that I disagree with the use of term private as meaning
non-inheritable. I think of private as an methods and attributes accessible
only within the namespace of that class or its descendants. Perhaps a better
term would be something like:
method foo is disinherited { ... }
I also need to separate out the DBC topic from the interface one. For
instance I have a hard time thinking about attributes in the context of
interfaces. For me, interfaces should be limited to a bunch of abstract
methods with conditions. Any other declarations within an interface IMO
should be errors. I.e., all other declarations belong in the implementation
class...
If you want to have a public and private "inheritable" interfaces that's
fine. But what's the point of a non-inheritable interface? Myself, I call
non-inheritable methods "functions".
> class ATV is Car, interface {
> attr _tilt is private;
> invar { ._tilt <= 20 } is private;
>
> method turn($direction, $how_sharp) {
> pre { $how_sharp <= 20 } is private;
> ...implementation...
> }
> }
An interface shouldn't have attributes. And per above, private
pre-conditions are pointless. I would rewrite the above as:
class ATV is Car, interface {
invar { .tilt <= 20 };
method tilt() is private; # in the "to class heirachy" sense
method turn($direction, $how_sharp) {
pre { $how_sharp <= 20 };
}
}
> I've implemented an ATV where I've put in a saftey
> protection against rolling over in a turn as both an
> invariant and a pre-condition. It will not allow you
> to turn the car too sharply, else it simply blows up.
> Wait second... ;)
>
> But I don't want my subclasses to be constrained by that.
> It's just an implementation detail that I only wish to
> enforce upon ATV and not it's children. So they're
> private.
>
> Makes sense, no?
No. Per DBC, pre-conditions are satisfied if either the inherited
pre-conditions _or_ its own pre-conditions are satisfied. Thus allowing the
loosening of input constraints which I believe is what you're after.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
