Graham Barr wrote: > > On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote: > > I think you just said the same thing I did. To be more explicit, using > > the terminology you seem to want to use, I'll point out that I was only > > talking about the case of an inherited method, not a _replacement_ > > method. In other words, when you inherit a method, you are taking the > > base implementation for that method. But if you replace a method, you > > are not inheriting that method, but rather replacing it; yes, the > > replacement method may choose to call the base implementation's method > > as part of the replacement implementation. When you replace a method, > > you have 2 subroutines, the base implementation, and the replacement > > implementation, but when you inherit a method, you have only 1 > > subroutine, which may be called 2 different ways. > > 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. 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? It was not my intention in the paragraph I quoted to say anything about pre and post conditions, but neither was it my intention to imply that they shouldn't be inherited, if they exist. 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. -- Glenn ===== Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
