> >PS> Perhaps the best of both worlds would be
> >PS> design-by-contract? A la Conway?
> >
> >Conway? Who's Conway?
>
> Dunno. He had some sort of thing a few weeks ago. The Public Conway 4.0 or
> something, I think it was. :)
According to the latest TPJ, he's "the Mad Scientist of Perl".
Clearly a trouble-maker of the worse kind!
> I think I'm missing the point. Why pull 'em out like that? Why not
> just put the code in the body of the sub?
Same reason that we prefer a while loop to goto: you collect in one place
all the relevant information that allows you to assess the correctness
of the subroutine.
An even better reason is that, by decoupling the interface contract from
the implementation details, you allow the conditions to be inherited by
methods in a derived class, even (or perhaps *especially*) when the
implementation is replaced.
Rest assured that I will be putting in an RFC proposing these and other
DBC constructs, as part of a suite of proposals for revamping Perl's OO
mechanisms.
Now, where did I leave that bucket of tuits???
> Though a good post condition would benefit from some sort of
> unconditional catch of return, I suppose. Perhaps allowing
> continue on the outer sub block...
Argh, no! A good postcondition is either invisible to the client code, or
makes its presence felt only through the effect of turning a bad final
state (or return value) into an exception. It does *not* offer a last
chance to monkey with the return value!
Damian
