Pre and Post Condition

[E-Bitch]

This applies to programming in the greater sense, but also drills down (my new favorite corporate term!!!) to perl.

Does anyone else use pre and post condition checking to build robustness into functions for perl programs? I know it is a bit extreme for a small program, but what about much larger ones?

Also, is there a module that can be used to verify pre and post conditions?

I.E.:

Psuedo Code:
use Cool::PrePostModule;
###
# some precondition documented here
# some postcondition documented here
###
sub functionname
{
   # get all yer args here
   &setPrecondtion('something == somethingelse');
   &setPostcondition('thisthing == thatthing');

   &checkPrecondition('somethingelse') or die 'I cant verify precondit
+ion';

   #yadayadayada

   &checkPostcondition('thatthing') or die 'I cant verify postconditio
+n';
}

Is this sort of construct a little too high level for the intended applications of perl programs?
_________________________________________
E-Bitch
Tempora Mutantur Nos et Mutamur in Illis
"The Times are Changed Even as We are Changed in Them"

[jwest]

Not at all - there are several CPAN modules that deal with this topic. Carp::Assert, for example, provides a nice set of functions that work nearly the same as the ANSI C assertion library.

I don't think there's such a thing as the defacto intended application of Perl programs, so solutions are provided for just about everything. Chances are, if its been done in other languages, someone has done it in Perl, too.

--jwest



-><- -><- -><- -><- -><-
All things are Perfect
    To every last Flaw
    And bound in accord
         With Eris's Law
 - HBT; The Book of Advice, 1:7

[princepawn]

one is Class::Contract, but my favorite is Carp::Datum.

[CheeseLord]

Not only do I rarely engage in pre-condition checking, I would discourage it. I'm sure people will disagree with me on this, but it seems to go against the way I want my code to go: the sub does what it says it does, and nothing more. I include documentation of the pre-conditions so that people calling my sub will know what they can send in - but I'm not about to tell them that they can't break the rules - I'm only stating that these are the only conditions which I'm sure my code operates correctly under (and even then I'm wrong sometimes).

I think it's analogous to a warranty - you see the terms of the warranty (the pre-condition), and it's up to you to handle the item correctly (passing correctly formatted / sequenced variables). If you choose not to, well, you might get what you want, or you might not. But you broke the rules, so I'm not gonna guarantee you anything in this case.

Don't let my ranting discourage you, though - do what you feel comfortable with. Certainly, checking that data is correct makes things nice for the user, but at the same time, you restrict the user's freedom. There's no real clear direction as to which is better - it's all about finding a good balance to that, I guess...

Update: I should point out that I am in no way saying that checking input is a bad idea - I mean, if perl didn't choke on syntax errors, you'd never have seen me here on PM. I just felt the need to bring up the point that adding in tons of input checks can result in your code becoming far too complicated, and can cause you to lose sight of your objective.

His Royal Cheeziness

[E-Bitch]

I see your point. I would say this, however... In order to make an application robust, I would say use the condition checking, and when making a utility (like a module), let it be flexible....

_________________________________________
E-Bitch
Tempora Mutantur Nos et Mutamur in Illis
"The Times are Changed Even as We are Changed in Them"

[John M. Dlugosz]

I call that a precondition regardless of whether the code checks it or not. Your docs list what the function assumes, rather than letting the user guess or incorrectly mix up implementation details with specifications.

[John M. Dlugosz]

Yes.

Years ago, I formalized a way to include preconditions in my C++ class documentation in a simple and useful way.

I specify which conditions are assumed vs validated. An assumed precondition means that you the caller better get it right, or the function will not behave as advertised. A validated precondition means that the code will catch this misuse (whether by throwing an exception, returning an error code, or whatever).

The concept of preconditions is very valuable for documentation, not just for making code super-robust. It lets you note the allowed range or restrictions on a function without cluttering up the prose description.

Checking some kinds of preconditions are done in the normal way: if n is greater than m, throw an error; etc. For ones that are not normally validated but you want in debug mode, in C++ the assert macro is often used. Without using a text preprocessor or waiting for Perl 6's lazy evaluation, I don't see an easy way to turn off checking by throwing a switch. The switch would be present in each statement: if ($debug && expensive_sanity_check(x)) ...

—John

[MeowChow]

Without using a text preprocessor or waiting for Perl 6's lazy evaluation, I don't see an easy way to turn off checking by throwing a switch. The switch would be present in each statement: if ($debug && expensive_sanity_check(x)) ...

Use a constant:

use constant DEBUG => 0; ... sub foo { sanity_check(...) if DEBUG; }

This has the nice effect of optimizing away the entire sanity check statement in production code, without employing a preprocessor/text-filter.

   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

[princepawn]

Without using a text preprocessor or waiting for Perl 6's lazy evaluation, I don't see an easy way to turn off checking by throwing a switch.

That's why I like Carp::Datum. It comes with a pre-condition stripper that you can use once you are read to go into production.

[MeowChow]

I noded something of a mini-manifesto on this subject here.

   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

[Dominus]

Have you seen Hook::PrePostCall? It is on CPAN.

--
Mark Dominus
Perl Paraphernalia

[E-Bitch]

Thank you all for your suggestions... I think I will go ahead and start attempting this.

_________________________________________
E-Bitch
Tempora Mutantur Nos et Mutamur in Illis
"The Times are Changed Even as We are Changed in Them"