> > 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.
Yup. It was just a snafu on my part. And if it's the only one in the 28
RFCs I put in, I'll be *most* surprised. ;-)
> > 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?
"Should not". "Could not" seems unnecessarily un-Perlish.
> If "should not", then perhaps a strict 'handlers' pragma would be nice?
Indeed.
> If "could not", is there an RFC which proposes a new syntax to distiguish
> the declaration of a subroutine from a method?
I don't believe it should be "could not" (that would make p52p6
translation much harder) but, if it were, I would have thought that:
sub name : method {...}
would cover that.
> > > the RFC has a glaring mistake: derived pre-conditions are
> > > supposed to be tested *before*, not after inherited ones!)
>
> Hmm. Would it still skip performing the inherited pre handlers if the
> derived pre was satisfied?
Yes.
> That is nice for Design-By-Contract... but what
> of Jarkko's RFC 194: Standardise Function Pre- and Post-Handling
> (http://dev.perl.org/rfc/194.html)?
You need to distinguish the OO use of pre/post from the non-OO use.
In the same way that we currently distiguish the OO use of subs from
the non-OO.
> Wouldn't you want all the pre-handlers invoked all the way up? Even
> if you don't care about the results of those pre's which are
> conditions?
Not for methods. Methods don't need inherited pre-*handlers*, since you
can already "wrap" them simply by providing an overriding method (one that
delegates via SUPER::) in the derived class.
Damian
