From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > >>>>> "Larry" == Larry Wall <[EMAIL PROTECTED]> writes: > > Larry> I think our terminology is getting sloppy here. What > Larry> do you mean by "inherit from that method"? If the > Larry> derived method overrides the base method, it will > Larry> manage its own resources, and doesn't need the base > Larry> method's LAST. If the derived method calls the base > Larry> method, the LAST of the base method will naturally > Larry> come along for the ride. If there is no derived > Larry> method, the base method also calls its own LAST as > Larry> a matter of course. I don't see any problem here. > > That's why I'm still puzzled about what it means to inherit PRE/POST > as well. > > A block of code doesn't have a superclass. What exactly are you > "inheriting from"?
I don't think PRE/POST are going to be part of the resources of a code block. They are part of the resources of a method. I don't know if they have any value in procedures. Perhaps only methods will be allowed PRE/POST? > If you call "super" from a method, surely the super will have its own > PRE/POST, and then there's no need to inherit it. If you don't call > "super", how do you know the PRE/POST of a similar subroutine in a > superclass that you're completely overriding should even apply? For DBC you want to inherit the SUPER's PRE/POST conditions even if you override the method's implementation. I don't thing PRE/POST apply to procedure subroutine, just the subroutines which are methods. Assuming we confine talk of PRE/POST to classes and methods... I think the latter statement about knowing when the PRE/POST of an inherited method/subroutine applies resolves itself. > So, does it make any sense at all to talk about "inheriting" PRE/POST > as a separate act, other than the natural block start/end from calling > "super" at the right time? Yes. As you might override the super's implementation, but still need to satisfy its PRE/POST conditions.
