in reply to proper Sub::Contract use

A few comments on your code:

As to your bigger question, if you want to identify the 'row' as well as the 'column' where the wrong value occurs, you could let information flow either way: You could pass &array_of_scalars the index of the row it's checking, so that it can incorporate that in the error message; or you could provide a way (by exception-throwing, probably) for &array_of_scalars to indicate to its caller the objectionable column, and adjust &array_of_array_of_scalar's error message accordingly. Also, yes, it looks (at a cursory scan) as if Sub::Contract can do what you want; but, if you are just concerned with checking for AoAs, then a simple grep is probably closer to what you want.

UPDATE: On further reading, Sub::Contract still requires you to write your own tests; and, since it says of error messages:

When a call to a contractor breaks the contract, the constraint code will return false or croak. If it returns false, Sub::Contract will emit an error looking as if the contractor croaked.
it sounds as if it won't give (on its own) the sort of specific error messages you want. Thus, you'll still need to write the tests (which you've mostly already done). If you want (as you seem to do, and should!) to use a module rather than rolling your own, Data::Validate::Struct might help (although, again, it seems to be going a bit overboard in this case).

Replies are listed 'Best First'.
Re^2: proper Sub::Contract use
by Anonymous Monk on Sep 03, 2008 at 07:07 UTC

    Thanks for the comments. $_ is corrected (my mistake) and (1) was there because I wanted to write about this line, as it should print "Scalar expected, reference found on position $index." when called normally, and "Scalar expected, reference found on position $index in row $row." when called from &is_array_of_array_of_scalar(). Just problem of finding context.

    Structures will grow and AoA will be part of another bigger one, so simple grep won't be enough.

    I tried exceptions mechanism, but I think It has no use here - there is no way to handle exceptions outside validation functions. I decided just to use warn "in cascades", so I get info message like this:

    V::is_array_of_scalar: Scalar expected, HASH reference found on positi
+on 2. Input:
$VAR1 = [
          'abc',
          'def',
          {
            'some' => 'any'
          },
          'x',
          'something'
        ];
V::is_array_of_array_of_scalar: Wrong value(s) in row 1. at scripts/li
+b/V.pm line 102.
input argument of [FDFr::compareArr] for key '-elem2' fails its contra
+ct constraint at (eval 12) line 31

    [download]

    but it will be pretty unreadable as V module will grow. So finally your hint about passing additional argument seems to be the best solution. If the function is called as top-level validator (no possibility to pass additional arguments), it will just print its error message, but if is called by other validation function, passing arguments is possible to pass any arguments and change messages. Thanks for ideas, I'm going back to work :)

[reply]
[d/l]
      I tried exceptions mechanism, but I think It has no use here - there is no way to handle exceptions outside validation functions. I decided just to use warn "in cascades", so I get info message like this:
      I think that your idea of warning in cascades is a good solution to the problem, so I don't want to discourage it, but I am confused by your qualification. What do you mean when you say that there is no way to handle exceptions outside validation functions? Unless I misunderstand what you're doing, all you have to do is wrap every validation in an eval {}, and check afterwards whether you caught an exception—which is not much more complicated than checking for truth or falsity anyway.
[reply]
[d/l]

In Section Seekers of Perl Wisdom