• I didn't realize that use can't be conditioned. I've fixed that and will be studying use, require and compile vs. runtime functions.
• I was checking the contents of %in before it was populated *blush*, and fixed it!
• I found node 30402 and especially merlyn's advice responding to the source node for the flawed algorithm. Is this really a problem if the script has no multi-valued params, and never will?
• I understand what you're saying about mixing CGI.pm interfaces. But i have tried it, and it works! :-)

Thanks again - epoptai

Is this really a problem if the script has no multi-valued params, and never will?

I think it is a problem, for two reasons:

1. You can never be sure that the script will never have multi-valued parameters. Who knows what features might be added in the future - and it might not be you that adds them.
2. By posting the code here you've made it an example that people will copy - and people who might not understand the specific circumstances that make your code work correctly. At the very least, you should have a comment that says something like "this code only works correctly because I have no multi-values CGI parameters".

I understand what you're saying about mixing CGI.pm interfaces. But i have tried it, and it works!

OK. I'll take your word for that. But does it give you any advantages over using one or the other exclusively? And once more, consider that your code will now be read and copied by people who don't understand it as well as you do. Would using one interface make it easier for them to understand? I think so.

--
<http://www.dave.org.uk>

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

Excellent points davorg. I wasn't doing the CGI thing for any reason so that's gone, and wasn't thinking out the full ramifications of posting code here, so have rewritten the hash generator with a simple &import_names('IN') while calling params with $IN::param in accord with the most concise advice i could find.