I like your idea. It's well suited for the example situation. But...
It doesn't scale.
If you have a long list of fields to test, maybe an unknown number of fields, it makes sence to stop checking in the moment you find a mismatch.

This sub (that I use in a project) is both generic and scales well. It's not as Perlish beautiful as some examples, but it's quick. As you will see, it's part of a module.

########################################################
# Return true if all parameters are either defined or
# undefined. Return false if there is a mix.
########################################################
sub defined_all_or_none {
#my $self=shift; # This is a module, remember?
shift;

@_||(return 1);

if(defined($_[0])) {
   for(@_) {
      unless(defined) {
         return 0;
         }
      }
   }
else {
   for(@_) {
      if(defined) {
         return 0;
         }
      }
   }
1;
}
[download]

Update:
Seeing it on the screen made me see clearer. :-)
The statement:

my $self=shift; # This is a module, remember?
[download]

shift;
[download]

f--k the world!!!!
/dev/world has reached maximal mount count, check forced.

Edit Masem 2001-07-13 - Code Tags

You need code tags so your [0] shows up...

Actually I like runrig's solution better than mine, it still goes through all the options, but it can be very simply tweaked to return which fields were empty, which is quite useful in this case. Your way will work, but since the calls for the data are retrieved via methods, and not a data structure, your way still has to call them all to be successful. You could do it otherwise, but then you would lose genericity. For something like this I prefer either a few lines of code in the prog, or a sub like yours that you pass params and a list of fields, but as I said, its not so generic any more....

                - Ant