Re^4: Experimental features: autoderef vs postfix deref

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

[kcott]

First up, no offence taken at all.

It would appear I'm missing something, but I don't know what it is.

I followed your link to state (in the node I responded to and again here). That's just a Super Search for the keyword 'state'. Nothing immediately useful there as far as I can see; I initially just shrugged it off as a typo, assuming you'd meant it to point to the state doco, i.e. http://perldoc.perl.org/functions/state.html. So, perhaps your link should point elsewhere - and that's the bit I'm missing.

The only other thing I can think of is that you did want $closure in

sub x1 { state $closure ... }
sub x2 { state $closure ... }

to reference to same variable. Or, at least, different syntax (or something) to achieve that sort of result.

[BrowserUk]

The only other thing I can think of is that you did want $closure in ... to reference to same variable.

Exactly.

With this syntax:

{
    my $closure;
    sub x1{ ... }
    sub x2{ ... }
    sub x3{ ... }
    ...
}

I can share the closure between as many subroutines as I need.

With embedded state, the closure's scope is restricted to the one subroutine.

I could do:

{
    state $closure;
    sub x1{ ... }
    sub x2{ ... }
    sub x3{ ... }
    ...
}

But then state has no advantage over the simple closure.

I did start to use state when it first appeared (there are probably several examples here somewhere), but after the third or fourth time of having to revert it back to a standard closure as needs changed, I simply stopped using it.