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]