Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

barbie (2653)

  reversethis-{ku. ... m} {ta} {eibrab}

Leader of [] and a CPAN author []. Co-organised YAPC::Europe in 2006 and the 2009 QA Hackathon, responsible for the YAPC Conference Surveys [] and the QA Hackathon [] websites. Also the current caretaker for the CPAN Testers websites and data stores.

If you really want to find out more, buy me a Guinness ;)

Memoirs of a Roadie []
CPAN Testers Reports []
YAPC Conference Surveys []
QA Hackathon []

Journal of barbie (2653)

Tuesday May 13, 2003
03:20 AM


[ #12159 ]
Jos Boumans got back to me about the suggestions I sent him. He has kindly made the following changes

1) Convert all keys to lowercase

I didn't like the idea that the module automatically returned all parameter names in lower case. However, as Jos had a need for this he wants to keep that as default, and has added the global variable $Params::Check::PRESERVE_CASE, which will be set to 0. I'm grateful for the addition, but still consider anything that changes what was input, should be at the users descretion. Plus although the default is TO_LOWER and we can PRESERVE_CASE, what if the user wanted TO_UPPER?

2) Weed out arguments that are not supported and warn about them to the user

Jos has now changed the following:

<     $VERBOSE                = 1;
>     $VERBOSE                = $^W ? 1 : 0;

Which is a fairer setting. However, it suddenly made me realise we were coming at this module from two very different perspectives.

Jos also wanted clarification as to what I meant by my suffix suggestion. Because I spotted the similarities between the module and my code, I'd assumed Jos was using it in the same way. However, now I don't think he is. Logically the name Params::Check suggests the module is just checking parameters, subroutine parameters. However, my code is checking CGI parameters, which is why the two issues above and the suffix suggestion are at odds with Jos's thinking.

I'll be writing to Jos with a better explanation of where I'm coming from, so hopefully he'll be able to see why the suffix suggestion would be a good idea. It also goes to prove that Params::Check is a very useful module being generic enough for two purposes, and perhaps others. Now I'm even more gutted I didn't think to do this first .... d'oh :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • You've seen Params::Validate [], right?
      ---ict / Spoon
    • I hadn't until I found Params::Check, but Params::Validate is more aimed at function paramaters, whereas I use CGI parameters. Params::Check fits better with validating CGI parameters and I personally prefer the interface.

      There is also Data::FormValidator [], but that only really deals with the existance of form fields in a form.

      All three are very close and could reasonably be amalgamated into one generic module, but I doubt that'll happen.

      • Patches welcome ;)
        • I seem to have an ability for spotting a bigger picture than module authors invisaged :)

          The problem with providing patches in this senario, is which module gets them? As I see it these three modules all provide a variation of validation for parameters. All three have little tricks the others don't have and all three could be coerced to validate the same set of parameters (whether functional or CGI), although Data::FieldValidation doesn't validate the contents based on rules.

          They all have their good poin

          • Actually, Params::Check is really similar to Params::Validate, it just highlights a different set of features in the docs.

            P::Validate offers the "allow unknown", and "strip leading dashes" features of P::Check. It also can optionally ignore case. Adding an option to convert keys to upper/lower case would be easy. It already handles defaults. It can die on unknown args, and adding support for just warning wouldn't be too hard.

            As to the validation pieces of P::Check, that can all be done via the P::Vali
            • I'm actually not totally oblivious ;)

              What you see happening here is abstracting out code from cpanplus (that's been in the source in one shape or the other for a year and a half), so they can be used in other (possibly related) projects.

              As I mentioned to barbie, the design decisions for P::C are very selfish, since CPANPLUS relies on it heavily and I pretty much implement into it any or all features CPANPLUS might require, hence releasing it as a module owned by me.

              I'm not at all opposed to merging th

  • Maybe to let you do what you want?

    # Emulate $Params::Check::STRIP_LEADING_DASHES $Params::Check::NORMALISE_KEY = sub { s/^-// }; # Combine $Params::Check::STRIP_LEADING_DASHES # and to lowercase $Params::Check::NORMALISE_KEY = sub { lc ; s/^-// }; # Example how to add it to the Params::Check source if ( ref $NORMALISE_KEY eq 'CODE' ){ $key = $NORMALISE_KEY->( $key ); } else { croak "$Params::Check::NORMALISE_KEY must be a coderef"; }

    You get the idea ...



    -- tex

    • <p>Poorly formatted code...</p>

      # Emulate $Params::Check::STRIP_LEADING_DASHES

      $Params::Check::NORMALISE_KEY = sub { s/^-// };

      # Combine $Params::Check::STRIP_LEADING_DASHES
      # and to lowercase

      $Params::Check::NORMALISE_KEY = sub { lc ; s/^-// };

      # Example of how to add it to the Params::Check source

      if ( ref $NORMALISE_KEY eq 'CODE' ){
         $key = $NORMALISE_KEY->( $key );
      } else {
         croak "$Params::Check::NORMALISE_KEY must be a coderef";


      -- tex