Re^2: Experimental features: autoderef vs postfix deref

[afoken]

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

[BrowserUk]

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

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

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

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

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"

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

[kcott]

"... 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 }
}

with the more succinct

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

[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 ... }

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

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).

[BrowserUk]

Sorry kcott, I hope you're not offended by this, but: grandmother; eggs :)

You've 'explained' everything (that I already knew) and completely skipped over, omitted, ignored the only important part of my explanation of why state is "flawed".

It only does half the job.

I do use state for purposes other than closures: typically, once-off initialization of variables used in a single subroutine

But "once-off initialisation of variables in a ... subroutine" is a closure! Just by a slightly different syntax.

And that slightly different syntax is flawed. Which is where I started.

[RonW]

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

{
    my $state_var;
    sub foo { ...; }
}

For that purpose, state works just fine.

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

[BrowserUk]

It is. But only for:

{
    my $state_var;
    sub foo { ...; }
}

But not for:

{
    my $state_var;
    sub foo { ...; }
    sub bar { ...; }
}

Which is a perfectly valid and common use of closures.

Thus it only deals with half the requirement. And so, (IMO), it is flawed.