FAQ 7.16 How do I create a static variable?

On reading this FAQ (posted to this forum yesterday) I didn't
understand what was going on.

Why would you want to do this? Would not a global variable suffice?
Or put another way, how would using a global variable fail but a
static variable fulfil a requirement.

Sorry if this is a basic question, but I just can't get my head around
it.


TIA


Owen

Owen <xemoth@gmail.com> wrote:
>On reading this FAQ (posted to this forum yesterday) I didn't
>understand what was going on.
>
>Why would you want to do this? Would not a global variable suffice?
>Or put another way, how would using a global variable fail but a
>static variable fulfil a requirement.

A global variable is visible and can be altered, well, globally, which
usually is A Bad Thing(TM).

A static variable is local to a specific subroutine and cannot be
accessed or changed outside of this sub, thereby ensuring that it still
has the same values as the last time the sub defined it instead of some
rouge piece of outside code.

jue

In article
<ae2aac97-af13-449b-8c71-5d92ee03cef5@b30g2000prf.googlegroups.com>,
Owen <xemoth@gmail.com> wrote:


> Why would you want to do this? Would not a global variable suffice?
> Or put another way, how would using a global variable fail but a
> static variable fulfil a requirement.

One of your biggest tasks as a programmer is to limit the action of any
one bit of code to the smallest scope possbile so it only affects what
it should affect, and nothing else. That's true regardless of the
language you use.

On Sep 7, 12:45*am, brian d foy <brian.d....@gmail.com> wrote:
> In article
> <ae2aac97-af13-449b-8c71-5d92ee03c...@b30g2000prf.googlegroups.com>,
>
> Owen <xem...@gmail.com> wrote:
> > Why would you want to do this? Would not a global variable suffice?
> > Or put another way, how would using a global variable fail but a
> > static variable fulfil a requirement.
>
> One of your biggest tasks as a programmer is to limit the action of any
> one bit of code to the smallest scope possbile so it only affects what
> it should affect, and nothing else. That's true regardless of the
> language you use.

Thank you, I don't have Perl-5.10, and on this 5.8.8. perldoc -f state
produces nothing

So it's time to install another Perl


Thank you

Owen

Owen schreef:

> I don't have Perl-5.10, and on this 5.8.8. perldoc -f state
> produces nothing
>
> So it's time to install another Perl

It always is,
but there are plenty of ways to create a static variable in a previous
Perl too.
Examples:

Alternative-1:

{ my $static;

sub a_sub_using_static {
# ...
}
}

The $static lives in in the "private environment" of the sub.



Alternative-2:

sub a_sub_containing_a_static {
my $static if 0;
# ...
}

The $static is properly created at compile time, but never reset at run
time.

--
Affijn, Ruud

"Gewoon is een tijger."

Dr.Ruud wrote:
> sub a_sub_containing_a_static {
> my $static if 0;
> # ...
> }
>
> The $static is properly created at compile time, but never reset at run
> time.

Eww. That makes for an interesting discussion point but please don't
encourage it. It's much to easy for an unwary programmer to extend the
idiom inappropriately, it's too clever for use in production code, and I
doubt that the current behavior is guaranteed to not change.

-mjc

In article <ga0p9p.g8.1@news.isolution.nl>, Dr.Ruud
<rvtol+news@isolution.nl> wrote:

> Owen schreef:
>
> > I don't have Perl-5.10, and on this 5.8.8. perldoc -f state
> > produces nothing
> >
> > So it's time to install another Perl
>
> It always is,

It's not time to install another Perl. Although you might have just
been glib with that remark, most people probably aren't looking at
constantly changing the plumbing:

* Find out if you really need or want the new features. before you
decide to upgrade. You should try to keep current, but you don't have
to rush.

* Don't install anything with .0 point release unless you're . So
for production stuff, wait until 5.10.1. Let other people experience
the pain of .0 releases.

* Don't wipe out your current Perl until you know the new Perl
doesn't somehow break whatever you've done.

Michael Carman schreef:
> Dr.Ruud wrote:

>> sub a_sub_containing_a_static {
>> my $static if 0;
>> # ...
>> }
>>
>> The $static is properly created at compile time, but never reset at
>> run time.
>
> Eww. That makes for an interesting discussion point but please don't
> encourage it. It's much to easy for an unwary programmer to extend the
> idiom inappropriately, it's too clever for use in production code,
> and I doubt that the current behavior is guaranteed to not change.

Its use is discouraged, somewhere in Perl's docs. (I remember it but
couldn't find it)

This "evil" idiom is not likely to disappear, because it is used a lot,
so you should at least know of it. (to be able to read it)
I actually like it and see nothing wrong with it.

The condition can also be a constant:

$ perl -Mstrict -Mwarnings -MData:umper -Mconstant=DEBUG,0 -e'
sub show {
my $log = 1 if DEBUG;
# $log ||= $Config{LOG};
return print Dumper $log;
}
show;
'
$VAR1 = undef;


But see also `perldoc -q static`, which points to "Persistent Private
Variables" in perlsub.

--
Affijn, Ruud

"Gewoon is een tijger."

Dr.Ruud wrote:
> Michael Carman schreef:
>> Dr.Ruud wrote:
>>> my $static if 0;
>>
>> Eww.
>
> This "evil" idiom is not likely to disappear, because it is used a
> lot, so you should at least know of it. (to be able to read it)

Happily, I've never encountered it in the wild. As of 5.10, it provokes
a warning:

Deprecated use of my() in false conditional

> I actually like it and see nothing wrong with it.

If someone unfamiliar with the construct came across code that used it
he'd have little chance of figuring out what did. I can find no hint of
it in perlfunc, perlsyn, or perlsub. That should be reason enough. I
don't much mind clever code that uses documented behavior, but this is
way across the line even for me.

It turns out that I didn't even understand how/why this works. I thought
that it was a combination of the compile-time effect of my() (defining a
lexical scope for a variable name) with its runtime effect (memory
allocation and initialization; disabled by the false conditional, and
thus static) and auto-vivification (to allocate the memory for the first
usage since my() didn't do it). I was pondering what sort of quirk would
have caused auto-vivification to allocate the variable in the scratchpad
instead of the symbol table.

Then I read perldiag, which says:

There has been a long-standing bug in Perl that causes a lexical
variable not to be cleared at scope exit when its declaration
includes a false conditional. Some people have exploited this bug
to achieve a kind of static variable.

So there you have it. It's a bug. Use it at your own peril.

-mjc