Damian Conway wrote:
> Because, by specifying the handlers separately, all the messy
> implementation details are automated and hidden. A single handler would
> foist them back on the programmer. One of the main uses (possibly *the*
> main use) of pre and post handlers is in Design-by-Contract OO
> programming, where there can be dozens or hundreds of handlers required.
>
> And -- more compellingly -- because the inheritance semantics of
> pre and post handlers are distinctly different. See:
>
Well, with those inheritance semantics, I believe the example
: pre read_file {
: flock $_[0], LOCK_EX;
: }
looses all its mean. Suppose the class whose method read_file has this
pre-handler is inherited of one class that has another read_file pre-handler
that only checks if the filename is not empty, or other silly stuff like
this. Then the flock would never be called, because the superclass' handler
got called and, as it didn't throw any exceptions, it don't need to call the
class' handler.
I agree that DBC is an important matter, and that a language like Perl
should support this. But, as far as I know about DBC, it's about
pre-conditions and post-conditions, not about pre-handlers. Of course,
pre-conditions and post-conditions can be implemented with pre- and
post-handlers, the way it's done in the section about Cat's and Tiger's, but
I believe this cannot be generalized, because the inheritance semantics is
only good in these cases. I mentioned the example about flock before, but I
believe it's also valid to all the taxes-related examples you gave also.
It's very dangerous to apply these kind of inheritance to things that have
side effects that can be or not be called, depending only on the behaviour
the superclass attaches to the same method!
I think I didn't make myself clear with my approach, I may eventually
rephrase it...
Thanks, Branden.
