Thanks Argel!
I appreciate what you have posted and I see your point. I think using undef makes sense when used also with 'defined', but here's my reasoning behind my original suggestion...
The question was:
"Should I make sure that I always pass 5 expected values to this sub routine even if I have to pass blank values, but preserving the order that the code is expecting them?"
The answer is yes to that question if the person asking is going to continue to use a list array method. I think Undef is only safer than 0 if you use 'defined' to check it, otherwise it's the same as 0, '', '0', right? At least that's what I got out of this perldoc:
http://perldoc.perl.org/functions/defined.html
Also, I thought 0 would be alright in this scenario based on what I interpreted the expected values to contain, but then again, it would be a mistake to assume data would be entered in any expected format, especially if it is coming in from a form.
If we don't use a hash this is a better solution:
build_url( $account, $transaction, undef, $fname, $lname);
sub build_url() {
... etc...
if (defined($location)) {
... stuff ...
}
}
Thanks! Dawn | [reply] [d/l] [select] |
No, 0 and undef are not always the same. Take 'fork' as an example:
Does a fork(2) system call to create a new process running the same program at the same point. It returns the child pid to the parent process, 0 to the child process, or undef if the fork is unsuccessful.
So 0 indicates it is a child process while undef indicates failure. Not the same.
In general, you should be checking for definedness if your data is coming from outside of the script anyway. I usually do something like 'if( defined $foo && $foo ne ""){}' That way I avoid warnings about doing a string comparison with an undefined value (or whatever the warning message says). You are using 'strict' and 'warnings', right?
Anyway, your code above looks good.
Elda Taluta; Sarks Sark; Ark Arks
| [reply] |
| [reply] |