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
Garrett Goebel wrote:
> From: Branden [mailto:[EMAIL PROTECTED]]
> >
> > I was reading RFC 271 and thinking about this pre/post
> > handler thing. Why instead of having 2 subs, one for
> > pre and other for post condition, and having to deal
> > with things as strange as $_[-1], why don't we
> > h
From: Branden [mailto:[EMAIL PROTECTED]]
>
> For example: suppose sub next_temp calculates a new
> temperature from an old temperature
[...]
>
> Suppose it only handles Celsius, and we want to be able to
> handle Fahrenheit and Kelvin also. We could do it by:
if you have a procedure:
sub nex
Branden writes:
> > 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;
> : }
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 inher
From: Garrett Goebel
>
> 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!)
Hmm. Would it still skip performing the inherited pre handlers if the
derived pre was satisfied? That is nic
> > 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 wa
