But you're correct; you don't get a warning.  And that's because you're not trying to use the value of $baseball{yankees}, you're only modifying it (ie. appending to it).

Note that you do get a warning if $baseball{mets} is undefined, as in:

use strict;
use warnings;

my %baseball = (
    orioles   =>   "baltimore",
    twins     =>   "minnesota"
);

if ($baseball{yankees} .= $baseball{mets})  {
    foreach $_ (keys %baseball) {
        print "$_ => $baseball{$_}\n";
    }
}

__END__
Use of uninitialized value in concatenation (.) or string at test.pl l
+ine 10.
[download]

Then what is being stated is that the line of code:

 
if ( $baseball{yankees} = $baseball{yankees} . $baseball{mets}
[download]

is not identical to:

 
if ($baseball{yankees} .= $baseball{mets})
[download]

Does this refute the original premise that: $a=$a <operator> $b; is same as $a <operator> = $b; (Taken from "Beginning Perl" by Lee & Cozens)?

That's a good question, but you'll find it in the on-line documentation.

From perlop (under Assignment Operators):

    Assignment operators work as in C. That is,

        $a += 2;

    is equivalent to

        $a = $a + 2;

    although without duplicating any side effects that
    dereferencing the lvalue might trigger
[download]

It's that last part, about avoiding dereferencing side effects, that comes into play here.

When you do:

    $baseball{yankees} = $baseball{yankees} . $baseball{mets};
[download]

you are incurring a side effect of dereferencing $baseball{yankees}, namely testing for definedness, which you won't incur when you use the assignment operator:

    $baseball{yankees} .= $baseball{mets}
[download]

---

s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/