state:barely used, and flawed; say: a pain to enable; /r: never seen the need.

• say is enabled together with strict in use v5.12;, that replaces use strict;.
• s///r is useful in map: @out=map { s/foo/bar/r } @in. Without /r, you need a helper variable: @out=map { my $x=$_; $x=~s/foo/bar/; $x } @in
• I don't get it. What's wrong with state?

Alexander

I don't get it. What's wrong with state?

Using normal closures, I can do:

{
    my $closure; 
    sub x1{ $closure = shift if @_; $closure } 
    sub x2{ $closure = shift if @_; $closure } 
};;

print x1( 123 ); print x2(); print x2(456); print x1();;
123
123
456
456
[download]

Or I can do:

{ 
    local our $closure; 
    sub x1{ $closure = shift if @_; $closure } 
    sub x2{ $closure = shift if @_; $closure } 
};;

print x1( 123 ); print x2(); print x2(456); print x1();;
123
123
456
456
[download]

Or:

sub x1{ our $closure = shift if @_; $closure } sub x2{ our $closure = 
+shift if @_; $closure };;

print x1( 123 ); print x2(); print x2(456); print x1();;
123
123
456
456
[download]

Try that with state:

sub x1{ state $closure = shift if @_; $closure } 
sub x2{ state $closure = shift if @_; $closure };;

print x1( 123 ); print x2(); print x2(456); print x1();;
123
Use of uninitialized value in print at (eval 22) line 1, <STDIN> line 
+14.

456
123
[download]

Or:

sub x1{ state our $closure = shift if @_; $closure } sub x2{ state our
+ $closure = shift if @_; $closure };;
No such class our at (eval 23) line 1, near "{ state our"
No such class our at (eval 23) line 1, near "{ state our"
[download]

So, three different ways to do something that works; and a new mechanism specifically designed to replace them that doesn't.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

"... and a new mechanism specifically designed to replace them that doesn't."

Firstly, I'm assuming that statement is based on the opening paragraph from "perlsub: Persistent Private Variables":

"There are two ways to build persistent private variables in Perl 5.10. First, you can simply use the state feature. Or, you can use closures, if you want to stay compatible with releases older than 5.10."

My interpretation of that, is that you can replace

{
    my $closure;
    sub x1 { $closure = shift if @_; $closure }
}
[download]

with the more succinct

sub x1 { state $closure; $closure = shift if @_; $closure }
[download]

[And similarly for: local our $closure;]

state variables are lexically scoped. If you declare two state variables (with the same name) in different scopes, e.g.

sub x1 { state $closure ... }
sub x2 { state $closure ... }
[download]

they will remain different variables: changing one has no effect on the other.

The form you presented with "sub x1{ our $closure = ..." loses the benefits of lexical scoping. $closure is now just aliasing a package variable accessible globally. A quick and dirty example:

$ perl -le 'sub x { our $c = shift if @_; $c } $::c = 1; print for x()
+, x(2)'
1
2
[download]

In closing, my assumption (stated initially) may be wrong; in which case, I'd be interested in the "specifically designed" part you mentioned. I do use state for purposes other than closures: typically, once-off initialization of variables used in a single subroutine (but that's, perhaps, getting a bit off-topic).

— Ken

My understanding of the description of state is as a short cut for:

{
    my $state_var;
    sub foo { ...; }
}
[download]

For that purpose, state works just fine.

I'm sorry, but I would not have expected your example to work.

I agree with all you've said here. I've played with all the new features you stated, but none ever provided me with enough benefit over what existed and I was used to, so I gave them up quickly. However, I'm sure some people do find value in them, it's just that I don't so much.

I'm going to try postderef, but in any real code I'll stick to the old fashioned way as it's guaranteed backward compatible (CPANTesters) and I just can't see it being removed any time in the even non-forseeable future.

-stevieb

Why is use 5.024 'a pain to enable'?

Because I'm currently on 5.18; one of my clients is on 5.14 and another on 5.10.

Because I'd have to remember which client's behalf I'm programming on; which version that client uses; which 'feeechers' that version supports; which 'mis-feechers' that version has dropped.

And then go through the whole damn game again when they decide to upgrade; and have to back out and replace the stuff that's 'gone away'.

Life's too short to ripple in the wind of every vanity project p5p allows through.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Because I'm currently on 5.18; one of my clients is on 5.14 and another on 5.10.

So Perl shouldn't get new features just because of your clients. Got it.