Leader of Birmingham.pm [pm.org] and a CPAN author [cpan.org]. Co-organised YAPC::Europe in 2006 and the 2009 QA Hackathon, responsible for the YAPC Conference Surveys [yapc-surveys.org] and the QA Hackathon [qa-hackathon.org] 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
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