in reply to Re^4: Experimental features: autoderef vs postfix deref
in thread Experimental features: autoderef vs postfix deref

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.


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!

Replies are listed 'Best First'.
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 { ...; } }

    is a perfectly valid and common use of closures, I would not want:

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

    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.

      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.


      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!

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