Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^2: How will you use state declared variables in Perl6?

by revdiablo (Prior)
on Jul 08, 2005 at 21:40 UTC ( #473574=note: print w/ replies, xml ) Need Help??


in reply to Re: How will you use state declared variables in Perl6?
in thread How will you use state declared variables in Perl6?

Closures are much safer.

Perhaps I'm misunderstanding, but I was under the impression that the Perl6 code:

sub foo { state $bar; $bar++; }

Was equivalent to the Perl5 code:

{ my $bar; sub foo { $bar++; } }

Which is a closure if I ever saw one. How is this safer? I'm not trying to blindly disagree with you, I'm honestly curious why the closure is safer.


Comment on Re^2: How will you use state declared variables in Perl6?
Select or Download Code
Re^3: How will you use state declared variables in Perl6?
by jgallagher (Pilgrim) on Jul 08, 2005 at 21:56 UTC
    I believe BrowserUK's point is that if foo is just a global subroutine, there is no difference. On the other hand, suppose you had
    package Bar; sub new { ... } sub foo { state $bar; $bar++; return $bar; }
    Then later...
    $bar1 = Bar->new(); $bar2 = Bar->new(); $bar1->foo(); # returns 1, as you would expect $bar1->foo(); # returns 2, as you would expect $bar2->foo(); # returns 3, possibly unexpected
    At least this is my understanding. Is this what you meant, BrowserUK?
      jgallagher,
      BrowserUk's response boils down to "don't use state variables as a replacement for class variables when doing OO". I agree with that. The argument that it will be easy to make this mistake is false though as p6 OO looks visually a lot different from p5 (method foo() vs sub foo() for instance). I am not saying caution isn't warranted, but this is just once case that doesn't negate the usefulness elsewhere.

      Cheers - L~R

      Update: I reworded my response to be clearer but I believe the spirit of the message was left in tact.

      Yes. That is a good example of the possible surprise factor.

      Now inherit Class Qux from Class Bar, and every time you call ->foo() from any instance of either class, state $bar will be incremented. This has the potential for an even bigger surprise factor I think.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
        Nah, it's only surprising if foo doesn't know it's a method. Methods should never be surprised by being inherited. And Perl 6 methods always know they're methods because they have their own keyword. If foo doesn't properly manage its own state, that foo's problem, not anyone else's.
Re^3: How will you use state declared variables in Perl6?
by Tanktalus (Canon) on Jul 08, 2005 at 22:00 UTC

    I don't think that's the type of closure BrowserUk is referring to. Think more of this perl 5 code:

    sub genclosure { my $bar; return sub { $bar++; } }
    Each time you call genclosure, you get a new closure, a new state variable. You don't reuse the previously existing state variable.

    So I would have to agree with BrowserUk's "very carefully" statement. The same as I would use your perl5 (global) closure code - very carefully. That said, I have probably about a half-dozen or so places where I need or want to cache data globally in my projects at work, so this would be very nice syntactical sugar for that. However, I also generate a few closures where this new idea could easily bite a junior programmer in the arse when they wonder why their data isn't returning properly. ("How did that counter get so high already?")

    That said, I also generally avoided static in C as well, so that's not really surprising for me. After all, one generally looks at programming tasks from the basis of their experience - if it looks like a nail, that may be because all you have is a hammer.

    Update: TimToady's response has cleared things up a bit, thankfully. It was looking a bit grim for state - although there is still some care to be taken. I'll have to think if I can figure out where I'd use this feature, if anywhere.

      If that's what he meant, this would be the equivalent Perl6 code, using state:

      sub genclosure { return sub { state $bar; $bar++; } }

      I'm still not seeing a difference in safety.

        That's correct--state variables clone. I see a lot of needless handwringing here based on the faulty assumption that Perl's state variables are just like C's static variables. There's a reason we gave them a different name...
        I'm still not seeing a difference in safety.

        If Limbic~Region's analogy with C statics is accurate, state defines an single, absolute, static piece of ram. So, this:

        sub genclosure { my $bar; return sub { $bar++; } }

        And this:

        sub genclosure { return sub { state $bar; $bar++; } }

        are semantically quite different.

        In the former case, each time you generate a coderef by calling genclosure(), that coderef will close over a different instance of the lexical $bar.

        In the latter case, each coderef generated will reference the same, single, immovable, static piece of ram</code> labelled $bar.

        And further, references to state $bar; in other unrelated generator functions--in the same package, or a different packages, or a different modules--will all refer to that same static piece of ram.

        It is possible that state will be cleverer than that, and somehow be scoped by file or package or namespace, but then a) the analogy with C static falls through; b) the would seem to be considerable overlap with local $bar;.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://473574]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (7)
As of 2014-07-28 04:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (186 votes), past polls