From: Glenn Linderman [mailto:[EMAIL PROTECTED]] > > Graham Barr wrote: > > But the base class may be just an interface class. And thus > > by inheriting the pre conditions you are enforcing the API. > > So I can see a use for it, but I can also see where you > > don't want it too. > > So if the base class is just an interface class, then you cannot > usefully inherit the methods, without winding up with just another > interface class. Of course, that sometimes is useful too.
Yes. For instance when making an implementation of the interface. The interface class can define the interface using abstract methods with PRE/POST conditions to specify what inputs are required and guarantee the output that will result. The implementation classes pick it up and go on from there. > So maybe your point was that when you replace a method from a > base class that you only have 1 subroutine for that method, > the replacement one, because there wasn't really one there > in the interface class to inherit? Exactly. > I'd still like to hear Larry comment on the benefits vs dangers of > having the PRE and POST conditions defined within the implementation > block of a method, as opposed to defined outside. The more I think > about it, the more convinced I am that the natural place to define the > pre and post conditions is outside the implementation block, > to prevent them from referencing lexically scoped variables of the > implementation... or have a compiler rule preventing it. > Otherwise they could be impossible to evaluate in the context of an > inherited (replacement) method. I think this has already been covered by the "no-side effects" rule for PRE-/POST- Conditions. Which Damian suggested could be implemented by: Damian Conway wrote: > By prohibiting mutation of variables not lexical to the block, > forbidding I/O, allowing calls only to already-defined subs, and > applying the same restrictions recursively to those subs.
