"Leon" <[EMAIL PROTECTED]> writes:
> ----- Original Message -----
> From: "Oliver Manickum" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> > When you use the 'my' operator, you define your variable,
> > resetting any data that was in it.
Actually, you "declare" a new variable, which may or may not
be "initialized". They main point here is that "my" is a
creator. It creates a new (lexically scoped) variable.
> It took me quite a while to figure out what you were
> trying to say. But my instinct tells me that what you were
> trying to say is that with each iteration, the variable my
> $b++ was resetted, hence no increment (remains as
It may *appear* that way, but that's not *exactly* what's
happening. What *is* happening is that every time you
specify "my", you _create_ a new variable. (That has the
effect of _resetting_ it, but there is no "reset" operation
taking place.) That newly created variable (with a value of
undef) is incremented (from 0 (the integer interpretation of
undef)) to 1. At the end of the loop (at the close brace,
actually) the variable is destroyed, reclaimed by memory,
and no longer accessible.
It's like having a new baby each iteration of the loop and
then giving it a birthday party. At the end of the party,
you'll always have a 1 year old baby. On the other hand, if
you give birth to that baby outside the loop, then every
time through the loop, you've got the same baby, and are
therefore correct in relying on that baby getting older at
every birthday party in the loop since it remembers its
state (history) from the previous iteration.
Births are expensive, but they *do* guarantee that you've
got a brand, spankin' new object to work on. But in this
case, you don't really want to go through all the expense
and resources only to have it destroyed (I'd say "die", but
that's another keyword) at the end. Skip the birth/death
cycle. Have one birth only. It's a lot less traumatic on
the parents (memory allocator) who have to provide the
nutrients (RAM) and energy (CPU cycles) for it's creation
(allocation). And then it dies once (and only once) when it
hits its end of life, but that's *not* at the end of the
loop, it's further down the program.
> 1), Members, please correct me if I've read Oliver wrongly.
>
> Normally if we declare a my $variable on a previous my $variable, the
> previous value is taken over by the latest value like this eg :-
> my $d = 100;
> my $d = 2;
> print $d; # value = 2
I think that the compiler should scream here. You're trying
to create two variables in the same scope with the same
name. Bad!
The following code is OK. Same name, but different scope,
therefore different variable.
my $d = 100;
{
my $d = 2;
print $d; # value = 2
}
print $d; # value = 100
> while ($b<3){
> $b++; # lets call this OUTER $b
> my $b++; # this $b does not take over the value of the OUTER $b
> # even though it is on the same block
> while ($b < 5 ) {
> $b++;
> print "2nd while \$b = $b\n";
> };
> };
The outer one is a global variable: $main::b or $::b
The inner one is a lexically scoped variable.
When dealing with "my", you can look at the line that
declares it, then backup to the smallest enclosing brace.
The variable belongs to that scope. A scope is defined by
an open/close brace pair. Lexicals are accessible anywhere
within the code of that scope.
--
Michael R. Wolf
All mammals learn by playing!
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
