> > 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
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
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
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]]
>
> 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
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
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
Branden wrote:
> 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 have only one handler that calls the real sub?
Becaus
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
> have only one handler that calls t
Branden wrote:
>
> Instead of:
>
> : pre abc { do_pre_handler(@_); }
> : post abc { do_post_handler($_[-1]); }
>
> why not make it:
>
> : pre_post_handler abc {
> : do_pre_handler(@_); # pre part
> : my $result = REAL_SUB::abc(@_);
> : do_post_handler($result);
>
Hi.
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 have only one
handler that calls the real sub?
Instead of:
: pre abc { do_pre_h
11 matches
Mail list logo
