David Golden wrote: > > I think this is a coverage vs correctness distinction. The idea that > I was trying to convey is that while these expressions use a boolean > operator for a shortcut, they aren't really about truth vs. falsity > of the overall expression, *except* when they are being used as part > of a conditional statement. From a coverage perspective, what > should matter in "my $foo = $p || $q" is that $foo takes on the > values of both $p and $q at some point during the test suite, not > whether or not $foo takes on both true and false values -- coverage > of that condition should be checked when $foo is used in another > expression.
I respectfully disagree. I think you're focusing too much on the low-level behavior of || returning one of its operands. That behavior makes Perl's syntax flexible and a little ambiguous. Because Perl doesn't make a distinction between "assign with a default value" and "perform a boolean OR" Devel::Cover it has to play it conservatively. You shouldn't shift the burden to somewhere else (where $foo is subsequently used) either, because you don't know how it will be used. It could be 1) a boolean in a condition 2) used in another "$a = $b || $c" type expression 3) an output that only appears in a print() statement ... In any of these cases, it's possible that $foo is really a boolean but by the method you proposed $foo would only be tested for taking both true and false values in the first one. Regardless, if that subsequent expression doesn't get full coverage the user is forced to trace the error back to where $foo was set -- something Devel::Cover could have done for them. (And more challenging if $foo is set in multiple places.) The moral of the story is that only the author knows exactly what "my $foo = $p || $q" means. It should be up to the author to analyze it accordingly. -mjc
