in reply to An example of programming by contract

This example takes the advice of tilly and chromatic with respect to how to write validation routines in a saner fashion.
=head1 METHODS =head2 factorial INPUT : a non-negative integer, n OUTPUT: the factorial of n =cut sub factorial { my $number = shift; return 1 if $number <= 1; return ($number * factorial($number-1)) ; } our %validate = ( non_negative => sub { $_[0] >= 0 }, integer => sub { 1 } ); sub validate { my $input = shift; my %arg = @_; for (@{$arg{as}}) { my $func = $validate{$_}; my $r = $func->($input); die "$_ validation failed" unless $r ; } return 1; } sub get { print "input? "; $_[0] = <>; } my $input; get($input) and validate($input, as => [qw(non_negative integer)]) and print factorial($input);

Replies are listed 'Best First'.
Re: Programming by Contract Example. revised
by dragonchild (Archbishop) on Nov 26, 2001 at 23:18 UTC
    Currently, as it stands, this system will trigger a warning if the $input isn't a number of some sort. That's because of the >= in the non_negative validation.

    Also, what if I did something like

    validate($input, as => ['blah']);
    Since $validate{'blah'} doesn't exist, you end up with a fatal error. A simple (if uninformative) change would be to
    for (@{$args{as}}) { my $func = $validate{$_} || next; my $r = $func->($input); die "$_ validation failed" unless $r; }
    Better would be to throw some exception or warning.

    Furthermore, you do know that this will be less efficient, execution-wise, than just putting the checks into the program. This methdology is best if you plan on doing the same checks on a large variety of inputs. (Of course, you're just playing, which is cool.)

    One possibility is to, instead of forcing the user to validate the input, have the function validate its own input using these functions. Or, maybe a wrapper around factorial(). That way, everything is encapsulated.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.