Re^7: Experimental features: autoderef vs postfix deref

[BrowserUk]

I would not want: ... to auto-magically assume both (or all at "same" level) declarations of $state_var to be the same variable.

I agree. That would be broken.

But having been bitten by having to convert uses of state back to the traditional form; I simply don't think the "convenience" factor is real. It's just not worth the (my) bother.

[RonW]

Having a background in C, I use "static" variables a lot. So, to me, Perl's "state" variables are the same thing.

(Also, I think it makes the usage clearer to the code reviewers and potential future code maintainers.)

(When I have real use case for a closure, I will code it that way. If it's just to "simulate" a "static" variable, I would rather use "state".)

[golux]

RonW,

I also have a C background, and agree about "state" variables being the Perl equivalent of C "static" variables.

Using "state" simplifies cases like the following where one shouldn't have to remember to print an HTML header, but also doesn't want it more than once:

#!/usr/bin/perl

use strict;
use warnings;
use feature qw{ state };

sub html {
    my ($text) = @_;

    # Make the header idempotent
    state $b_header++ or print "Content-type: text/html\n\n";

    print $text;
}

html("<br>This is some html, prior to which a header is printed\n");
html("<br>This is too (but the header was printed already)\n");

Output:

Content-type: text/html

<br>This is some html, prior to which a header is printed
<br>This is too (but the header was printed already)