< Russ:
>> About the only piece of code of mine that this would affect are places
>> where I use ++ on an undef value, and that's not a bad thing to avoid as a
>> matter of style anyway (usually I'm just setting a flag and = 1 would work
>> just as well; either that, or it's easy enough to explicitly initialize
>> the counter to 0).
< Philip:
>Depends. While it is possible to initialise counters in the canonical
>"have I seen this before" situation, it's more convenient the way it is at
>the moment:
> $seen{$word}++;
>looks, to me, nicer than
> $seen{$word} = (exists $seen{$word}) ? 1 : $seen{$word} + 1;
er, flip that.
>or
> if(defined($seen{$word})) { $seen{$word}++ } else { $seen{$word} = 1 }
>or similar.
In general, if you can get away with a simpler expression, it's better.
For example,
if ($foo && is_whatnot($foo))
is inferior to
if ($foo)
just as
if (!$foo && !is_whatnot($foo))
is inferior to
unless ($foo)
"Inferior by what metric?" you ask? Complexity.
Larry wrote (in Camel-3) that
...the autoincrement will never warn that you're using undefined values,
because autoincrement is an accepted way to define undefined values.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So I think you're safe there.
He also wrote:
The C<||> can be used to set defaults despite its origins as a
Boolean operator, since Perl returns the first true value. Perl
programmers manifest a cavalier attitude with respect to truth,
since the line above would break if, for instance, you tried
to specify a quantity of 0. But as long as you never want to
set either C<$quality> or C<$quantity> to a false value, the
idiom works great. There's no point in getting all superstitious
and throwing in calls to C<defined> and C<exists> all over the
place. You just have to understand what it's doing. As long
as it won't accidentally be false, you're fine.
Simple true and simple false are best if your goal is simplicity.
Sometimes you need more than that. So you write functions. Or,
if you're into the quirks of using strange magic of occasionally
dubious charm, then through operationally overloaded objects.
--tom
