Making -w happy

[chantstophacking]

...I am familiar with code constructs that bend a little backward to satisfy Lint, or some other code cleanliness mechanism. And I've done my own bending w/r to Perl when I need to be sure that either -w, or strict, or require demand that code be laid out in a certain fashion.

But I'm having a little trouble seeing why the following code (from DBD::mysql test suite) is necessary:

my $host = shift @ARGV || $ENV{'DBI_HOST'}
  || $::test_host || $::test_host;  # Make -w happy

I'm okay with the concept that $host will be set to the first appropriate value from the subsequent list of logical alternatives. I just don't get why the second reference to $::test_host. And for that matter, I'm not sure why $::test_host instead of $test_host. I presume that we're operating in the Main package here, so in either case we're talking about the same variable.

What have I missed?

[Corion]

$::test_host is a variable that will be skipped by the strict checks, because it is fully qualified. Such a variable would have to be either defined via use vars qw( $test_host ); or on the command line via -Dtest_host=foo - the more likely case. Then, warnings would warn that $::test_host was only used once in the program source, and the double test tricks warnings there.

In my opinion, it would be be better to locally disable that warning than to test $test_host twice, as it is not really obvious ...

my $host;
{
  no warnings 'once';
  $host = shift @ARGV ||$ENV{'DBI_HOST'} || $::test_host;
};

Update: s!strict!warnings!g

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web

[chantstophacking]

...thanks. That explains exactly what I was wondering about. (Honorary ++, although it will probably be a few more days before I can cast a vote explicitly.)

I agree with your suggestion that locally disabling "strict" is a better approach than cleverly circumventing it. Exposes the intent of the code more clearly.

That's what I used to do with Lint as well. Better to dumb down the warnings locally than to invent special variables to satisfy its artificial complaints. With your help though, I can see what the author intended here. Thanks.