Pls help old perl-monger with new version syntax?

[Rainer Weikusat]

Yes there is. In the first example $i is scoped over the loop block,
rather than the whole sub. Even in an example like this:

sub foo {
my ($x) = @_;
$x or return;
my $y = ...;
}

$y is in a smaller scope than $x, that scope just doesn't happen to be a
full BLOCK.


No, it's a stupid retort based on a complete misunderstanding of the
example,

I assumed that 'inner scope' was sufficiently clear to be understood
as it was meant, namely, variable declared in a block contained in
another block. Actually, I very strongly suspect that you did
understand that as well and consequently, I also suspect that you are
completely aware that you are evading the discussion by starting a
sideline quarrel on something which doesn't reall matter.

 

[Rainer Weikusat]

I long since plonked Herr Weikusat.

The interesting question is: Why do you feel the desire to talk about
that?

 

[Rainer Weikusat]

The interesting question is: Why do you feel the desire to talk about
that?

I'll even take the liberty to supply an answer to that: Begging for
approval.

 

[Jürgen Exner]

The snippet of code I included in my post was an attempt to come up
with a process that would initialize these fields if they were not
aleady defined. That's why I used the unless defined clause.

By using 'my' you just created this local variable, therefore by
definition this variable will be undefined. Therefore your check for
defined() is meaningless, even if the right-hand side were referencing
the new local variable (it is not!).

Introduce variables when you need them and where you need them. Unless
there are exceptional circumstances you should know the real desired
initial value at that time and there should be no need to initialize
them to some dummy value.

My understanding of this function was that it was the perl equivalent
of the php isset function. However, even when I remove the unless
portion of the statements I still receive the same use of
uninitialized variable blah blah.

I don't believe you.

A
my $ln = '';
compiles and runs perfectly fine, even with strict and warnings enabled.

All I'm trying to do is understand how I can satisfy the syntax so the
programs resume working. They were in production.

Maybe you should think about semantic first. Do you now what "my" does?
If you don't then adding random statements into your code is not likely
to fix anything.

So please keep up the comments as I and I'm sure others find them
informative. And if you understand my issue more clearly perhaps more
suggestions will follow.

Honestly I don't. If you want to refactor your code to take advantage of
new Perl features, then that's great.
But new versions of Perl are usually quite backward compatible.
Therefore usually there is little need to change anything to make older
programs run with newer versions. Yes, that is a generalization and
there are counter-examples, but "my" isn't one of them.

Or to put it in different words: if you want to change your code from
global variables to local variables then IMNSHO this is a great idea.
But it has nothing to do with switching to a newer version of Perl.

jue

 

[Eric Pozharski]

Probably 5.8.8 or 5.10.0. The code you posted definitely wouldn't have
worked with those versions.

according to <http://distrowatch.com/table.php?distribution=ubuntu>, it
was 5.10.0.

*CUT*

 

[Wolf Behrenhoff]

Am 25.07.2012 18:59, schrieb Rainer Weikusat:

Just to make sure I understand you correctly: given the two following subs:
[...]
are you suggesting to prefer bar over foo because in foo the scope for
$i is limited to the loop?

There's no variable being declared in an inner scope in either example
so why do you ask? (NB: That's a stupid retort based on tangential
technicalities of the example).

I didn't put "Just to make sure I understand you correctly" for fun!
Based on your reply I assume the answer is "no".

I assumed that 'inner scope' was sufficiently clear to be understood
as it was meant, namely, variable declared in a block contained in
another block.

So, would this example be the "correct" one:

sub foo {
...
for my $i (1..100) {
my $inner = do_something($i);
...
}
...
}

The $inner is now declared in a block (the "for") of a block ("sub"). So
the $inner should be declared before the loop?

We could even make it more inner, for example
sub bar {
for my $x (1..5) { for my $y (1..5) {
my $inner = $array2d[$x][$y];
...
}}
}

Maybe I really completely misunderstood what you've said... Why not make
an example to clarify what you really mean?

 

[Rainer Weikusat]

Am 25.07.2012 18:59, schrieb Rainer Weikusat:

Wolf Behrenhoff <[email protected]> writes:

[...]

I assumed that 'inner scope' was sufficiently clear to be understood
as it was meant, namely, variable declared in a block contained in
another block.

So, would this example be the "correct" one:

sub foo {
...
for my $i (1..100) {
my $inner = do_something($i);
...
}
...
}

The $inner is now declared in a block (the "for") of a block ("sub"). So
the $inner should be declared before the loop?

Decidedly yes, because (AFAIK) this code creates a new my variable on
each iteration and creating 100 different 'use once' variables instead
of using one variable 100 times is seriously wasteful. But that's a
different question.

We could even make it more inner, for example
sub bar {
for my $x (1..5) { for my $y (1..5) {
my $inner = $array2d[$x][$y];
...
}}
}

Maybe I really completely misunderstood what you've said...

And maybe, you are deliberately constructing nonsense-examples by
exploiting ambiguities in natural language. The fact that you've
adjusted your example to be still applicable to my clarified statement
suggests so. Since natural language always contains ambiguities, you
will succeed in finding a way to misinterpret whatever else I may
write on this topic until kingdom come.

 

[Rainer Weikusat]

[...]

sub foo {
...
for my $i (1..100) {
my $inner = do_something($i);
...
}
...
}

The $inner is now declared in a block (the "for") of a block ("sub"). So
the $inner should be declared before the loop?

Decidedly yes, because (AFAIK) this code creates a new my variable on
each iteration

According to a simple experiment I just made, this seems to be wrong.
In this case, this means the complete for-statement would be a good
candidate for becoming its own subroutine, except that it already is
'its own subroutine' in these pathological examples because the code
outside of it does nothing: This is no longer a case of using nameless
'subprograms' inside a larger aggregate but just an attempt to confuse
the reader as much as possible (not really applicable to this
contrived example) by using 'hand-optimized' individual lifetimes for
(possibly) all variables declared inside a subroutine: There a fifteen
$i in here and they are all different!

-----------
use Devel:eek;

for (1 .. 2) {
my $a = 4;

Dump($a);
$a = 5;
}

 

[David Canzi]

I assumed that 'inner scope' was sufficiently clear to be understood
as it was meant,

It wasn't.

 

[Rainer Weikusat]

[...]

sub foo {
...
for my $i (1..100) {
my $inner = do_something($i);
...
}

[...]

this code creates a new my variable on each iteration

According to a simple experiment I just made, this seems to be
wrong.

Likely, the test in the previous posting was too simplistic and the
two variables just happened to be using the same memory area. The code
below:

-----------
my @s;

for (0 .. 1) {
my $a;

$s[$_] = sub { return ++$a; };
}

print $s[0]->(), "\n";
print $s[1]->(), "\n";
print $s[0]->(), "\n";
print $s[1]->(), "\n";
------------

shows that there are indeed two independent variables being created
and according to

------------
use Benchmark;

timethese(-20,
{
a => sub {
for (1 .. 1000) {
my $a = $_;
}
},

b => sub {
my $a;

for (1 .. 1000) {
$a = $_;
}
}});