At 04:50 PM 2/17/2006, Robert May wrote:
my is a compile time directive that creates the lexically scoped $i,
giving is scope from its definition until the end of the enclosing block.
Assignment is a run time operation. In your example the modified
assignment doesn't get executed, so the value of $i is *not
defined*, in current perl's it happens to take the 'undef' value.
<quote>
NOTE: The behaviour of a my statement modified with a statement
modifier conditional or loop construct (e.g. my $x if ...) is
undefined. The value of the my variable may be undef, any previously
assigned value, or possibly anything else. Don't rely on it. Future
versions of perl might do something different from the version of
perl you try it out on. Here be dragons.
</quote>
OK, this was an excellent explanation of what is going on, so now I
understand it and can thus avoid it. Still, we have the following
situation: A construct in the language which is syntactically valid
has an undefined behaviour. And, I admit, if I had read all of the
voluminous Perl documentation, I would have eventually come across
that fact. Furthermore, that construct has a behaviour that should
never occur in a programming language, namely, a variable local to a
function retains its value across invocations of that function.
I might further point out that with both "use strict" and "use
warnings", there is no indication that I've used a bad construct in
the code. When I execute with "use strict" and "use warnings", there
are some warnings, but only having to do with use of uninitialized
values in '==' comparisons and '.' operators. When we have a
construct that is easily detected by the compiler, and has an
undefined result, with warnings in the documentation about its use -
how can there not be a warning generated?
_______________________________________________
Perl-Win32-Users mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
