develooper Front page | perl.perl5.porters | Postings from April 2000

opcode vs. Perl text in warnings

From:
Wolfgang Laun
Date:
April 3, 2000 09:52
Subject:
opcode vs. Perl text in warnings
Message ID:
38E8BE1C.A22FB20D@alcatel.at
Porters and company,

having read the discussion in connection with the
"use of uninitialized value in concatenation (.)"
warning, I might just as well admit that I'm among
the dummies, because I fell for that one in a line
like

   if( "a${foo}b${bar}c" eq $blech{x} . $blech{y} ){...

I wasted quite some time checking $blech{x} and $blech{y}
before I even began looking at $foo and $bar.


What had happened before:

I had read the Camel book: It told me that
interpolation is "really just a handy form of string
concatenation". It also taught me that interpolating
an array is "equivalent" to a join() - which is not
explained in terms of "concatenation" (but most likely
*does* concatenate strings ;-).

My own experience had shown me that not every
interpolation is necessarily a concatenation 
(e.g. "$foo" ), so I was inclined to take that
Camel explanation of interpolation cum grano salis.

Earlier on, I'd also gotten a warning for a line like

   $s = join( ",", @ary );

where some in-between value of @ary was undefined.
That this pointed me straightforward to a *join*
operation was a pleasant surprise.

Now, coming back to that first line: Seeing that Perl
is capable of distinguishing between `.' and `join' at
runtime, how [deleted] was I supposed to know that it is
*not* capable of distinguishing between interpolative
context and explicit `.' or explicit `join'?

Obviously it is not sufficient to know what Perl *can*
do, so as not to be thrown in with the dumb ones - one
also would have to know what Perl *cannot* to.

Quod erat remonstrandum.

Regards,
-Wolfgang



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About