You can make your enclosing block a BEGIN block, or you can put it above the rest of your code.

Update: In the days and weeks after the debate that followed this comment of mine, through reading and CB conversations I have convinced myself that INIT blocks are not "up to spec", so I'm avoiding them. See in particular TimToady's node in this thread.

---

In the TIMTOWTDI vein, I'm partial to INIT blocks myself:

use strict;
use warnings;

test() for (1..3);


{
  my $memory;
  INIT { $memory = 'a' }

  sub test {
    print "Value of static var is ", $memory++, "\n";
  }
}
__END__
Value of static var is a
Value of static var is b
Value of static var is c
[download]

I like using an extra internal INIT block only because it clearly sets the initialization code off from the rest.

Of course, if one doesn't like INIT or BEGIN blocks, one can always explicitly check in test that $memory has been initialized and remedy the situation if necessary, but that's ugly, IMO.

the lowliest monk

I'm partial to INIT blocks myself

Noooooooooooo! Please please please don't do that! It will break if you put the code using the INIT block in a module and that modules is directly or indirectly required (i.e., loaded after program compile-time). INITs are not executed right after the file in which it was found is done compiling. It's executed after the program file is done compiling. INIT is used when you need to do something delay execution of something to before program run-time.

Personally I go with adding a BEGIN before the bare block, thus avoiding to retype the variable name.

BEGIN {
  my $memory = 'a';

  sub test {
    print "Value of static var is ", $memory++, "\n";
  }
}
[download]

Update: added clarification.

ihb

See perltoc if you don't know which perldoc to read!

Thanks for the catch! I'm not initializing the variable in my actual code, and only set $memory = 0 in my post on a whim. But it illustrated a subtlety I would have probably missed on my own. And your comment seems to have sparked a lively and interesting debate on BEGIN vs. INIT blocks.

Yep. And I would see the possibilities (e.g. sharing static var's for a subset of functions) as a win.

---

Ordinary morality is for ordinary people. -- Aleister Crowley

use strict;
use warnings;


my $test = test();

$test->() for (1..3);
$test->() for (1..3);

sub test{
    my $var = 1;
    return sub {
        print("private state is ", $var++, "\n")
    };
}

__STDOUT__
private state is 1
private state is 2
private state is 3
private state is 4
private state is 5
private state is 6
[download]

#!/usr/bin/perl

use warnings;
use strict;

my $counter = 0;

&mySub;
&mySub;
&mySub;

sub mySub {
  print "My Value is ", $counter++, "\n";
}
[download]

sub foo {
    my $x if 0;
    print "X is ", $x++, $/;
}

foo() for 3 .. 5;
----
X is 0
X is 1
X is 2
[download]

It is documented. It is documented as being undefined behaviour, which is even less reliable than undocumented.

Lately i could argue its written in Martian Genius C and not the normal plain C that most of us know.

---
demerphq

I'm letting you access the raw value of the counter through hash syntax so you don't need to use Exporter. You could also put everything from package StaticCtr to just before package main into another file, StaticCtr.pm (end it with 1;). Then you can use StaticCtr; in any of your programs.

The new subroutine could be just a line really, it is longer so you can play with it more (see the perlobj manual).

#!/usr/bin/perl

package StaticCtr;

sub new {
 my $this = shift;
 my $class = ref($this) || $this;
 my $self = {};
 bless($self, $class);
 $self->{ctr} = 0;
 return $self;
}

sub inc {
 my $self = shift;
 $self->{ctr}++;
 return $self->{ctr};
}


package main;

my $c = new StaticCtr;

for (1..6) {
 print " incremented to: " . $c->inc . "\n";
}

print "Final value is " . $c->{ctr} . "\n";
[download]

[mattr@taygeta perlmonks]$ ./ctr.pl 
 incremented to: 1
 incremented to: 2
 incremented to: 3
 incremented to: 4
 incremented to: 5
 incremented to: 6
Final value is 6
[download]

Unforuately, a reference to the object must be passed to the function, and the OP explicitely requested that the solution didn't do this. I do like passing a state object as you suggest, though. There's much less hidden mojo that way.

Sorry for this banal reply. The original version of it was completely wrong.

Ah, my bad.
I was a little confused what he was getting at. Also was thinking "well you could use a global but that would not be so elegant.." etc. I guess there is a good time to use closures like above.
Thanks!
Matt