Re^3: Experimental features: autoderef vs postfix deref

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!

Comment on Re^3: Experimental features: autoderef vs postfix deref Select or Download Code

Replies are listed 'Best First'.
Re^4: Experimental features: autoderef vs postfix deref by kcott (Archbishop) on Jul 12, 2015 at 20:49 UTC
"... 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	[reply] [d/l] [select]
Re^5: Experimental features: autoderef vs postfix deref by BrowserUk (Patriarch) on Jul 12, 2015 at 21:14 UTC
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. 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!	[reply]
Re^6: Experimental features: autoderef vs postfix deref by kcott (Archbishop) on Jul 12, 2015 at 22:55 UTC
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 ... }` [download] to reference to same variable. Or, at least, different syntax (or something) to achieve that sort of result. — Ken	[reply] [d/l] [select]
Re^7: Experimental features: autoderef vs postfix deref by BrowserUk (Patriarch) on Jul 12, 2015 at 23:13 UTC
Re^8: Experimental features: autoderef vs postfix deref by kcott (Archbishop) on Jul 13, 2015 at 13:52 UTC
Re^4: Experimental features: autoderef vs postfix deref by RonW (Parson) on Jul 13, 2015 at 18:01 UTC
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.	[reply] [d/l] [select]
Re^5: Experimental features: autoderef vs postfix deref by BrowserUk (Patriarch) on Jul 13, 2015 at 18:14 UTC
It is. But only for: `{ my $state_var; sub foo { ...; } }` [download] But not for: `{ my $state_var; sub foo { ...; } sub bar { ...; } }` [download] Which is a perfectly valid and common use of closures. Thus it only deals with half the requirement. And so, (IMO), it is flawed. 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!	[reply] [d/l] [select]
Re^6: Experimental features: autoderef vs postfix deref by RonW (Parson) on Jul 13, 2015 at 19:53 UTC
While I agree that: `{ my $state_var; sub foo { ...; } sub bar { ...; } }` [download] is a perfectly valid and common use of closures, I would not want: `sub foo { state $state_var; ...; } sub bar { state $state_var; ...; }` [download] to auto-magically assume both (or all at "same" level) declarations of $state_var to be the same variable. I am pretty sure that `state` was not designed as a replacement for "traditional" closure constructs, rather just as a short cut for a specific use case.	[reply] [d/l] [select]
Re^7: Experimental features: autoderef vs postfix deref by BrowserUk (Patriarch) on Jul 13, 2015 at 20:05 UTC
Re^8: Experimental features: autoderef vs postfix deref by RonW (Parson) on Jul 13, 2015 at 20:34 UTC
Some notes below your chosen depth have not been shown here