Michael, I appreciate that you've thought about my post enough to
respond, but I think that a calmer and less reactionary response would
be more effective. This is not USENET. Flames don't help collaboration.
I say this because, in your heated reply, you missed a major point of
my post.
[MJCARMAN - Mon Feb 21 09:46:30 2005]:
Show quoted text> [DAGOLDEN - Mon Jan 31 20:46:26 2005]:
>
> > It might be worth considering whether OR operators should be treated
> > as equivalent to the trinary operator except when called in boolean
> > context.
>
> Absolutely not! Suppose the boolean context is:
>
> if ($a || $b) {
> # do something
> }
>
> Would you still want to ignore the (0,0) case?!
If you note the "except when" clause in what I wrote, I'm clearly not
suggesting ignoring the (0,0) case in your example. Whenever the ||
operator is used in a context that expects a true/false value, it should
be tested for the full truth table.
However, when this is not the case -- when the || operator is *not*
being used in boolean context, the meaning of an expression using ||
changes from the logical question of "true or false" to the semantic
question of "first value or second value".
My parallel to the trinary operator is that it is a semantic equivalent
outside of a boolean context and that the coverage issue is a branching
one, not a conditional one. Consider:
$a = $b || $c;
$a = $b ? $b : $c;
The only semantic question posed in the code is whether $b or $c is the
result assigned to $a; the only condition that matters is whether $b
evaluates to true or false. In this context, the truth/falseness of $c
is irrelevant.
[As a side note, I certainly agree that these constructs are not
equivalent at the opcode level, as the trinary example evaluates $b
twice, which could be very bad if I wasn't using a variable but rather
an expression that had side effects (e.g. "--$b" ). I am merely making
an analogy.]
Show quoted text> Devel::Cover is doing the right thing here.
This is the only real point of contention, I think. I would prefer that
Devel::Cover "do what I mean" and adjust its logic for the semantic
context of the expression. I futher hypothesize that *if* Devel::Cover
can determine if an || expression is in boolean context or not (as the
Want module implies is possible), then it should be able to correctly
avoid false positives in this way.
