From: Branden [mailto:[EMAIL PROTECTED]]
>
> Well, with those inheritance semantics, I believe the example
>
> Damian Conway writes:
> :
> : 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.
Yes... in order to make RFC 271 useful for both generic handlers _and_
conditional checks, you'd have to make it perform the ancestral pre-handlers
and the derived ones, and only hiccup if they both throw exceptions. Or do
it the way Class::Contract does and satisfy the derived class first, then
failing that the ancestors.
This just in "Damian Conway writes":
> the RFC has a glaring mistake: derived pre-conditions are
> supposed to be tested *before*, not after inherited ones!)
Okay... good... nix. You'd want/need pre's called in derived-first order
anyways to hide the messy implementation details of base classes.
Damian Conway writes:
> You need to remember that pre/post conditions play a dual role in
> Perl that mirrors the dual role of subroutines.
>
> In non-OO packages, subroutines are called directly, and pre/post
> handlers are available to modify their behaviour.
Are you suggesting that using pre/post handlers in the context of methods
"could not" or "should not" modify the method's @_ and implementation
behavior?
If "should not", then perhaps a strict 'handlers' pragma would be nice?
If "could not", is there an RFC which proposes a new syntax to distiguish
the declaration of a subroutine from a method? And what of translating the
obscure Perl 5 case of procedures that can act as both subroutines and
methods? (I believe CGI.pm and File::Spec do this).
Garrett
