in reply to Re^2: no chunk is too small
in thread Last undefines a for loop's itererator?

If it doesn't work under warnings and strict, there is probably a good reason for that. IMO, if you want to access the loop variable outside the loop, you should declare a separate variable and set it explicitly before you drop out of the loop.
It does work fine under warnings and strict, if you don't declare your variable in the conditions on the for(..) loop. It has always seemed weird to me to write code like
my $iold; for my $i ( 1 .. $foo ) { if( bar($i) ) { $iold = $i; last; } }
Doesn't it just seem like a waste of variables? You're clearly using $i and $iold for the same purpose.

As for why it isn't a subroutine, perhaps because I like this code all in one place. Shrug.

Replies are listed 'Best First'.
Re^4: no chunk is too small
by ewilhelm (Novice) on Nov 14, 2005 at 17:22 UTC

    It has always seemed weird to me to write code like

      my $iold;
      for my $i ( 1 .. $foo ) {
        if( bar($i) ) {
          $iold = $i;
          last;
        }
      }
    

    Doesn't it just seem like a waste of variables? You're clearly using $i and $iold for the same purpose.

    No, you're using $i as a loop variable and $iold as the return value of the loop. Variables are cheap. Using them to buy clarity is a "good deal"™.

    As for why it isn't a subroutine, perhaps because I like this code all in one place. Shrug.

    This code is all in one place. It is just a loop with a return value. Read carefully.

    my $iold = sub { for my $i ( 1 .. $foo ) { if( bar($i) ) { return($i); } } }->(); # calls this anonymous sub (setting $iold)

    Note that it takes the same number of lines to set an external (to the loop) value and last; as it does to define your loop as an anonymous sub and return($i);

    This also gets you the benefit that if the loop gets more complicated or needs to be reuse, refactoring just means yanking it verbatim and making it a named sub because nothing inside of it relies on lexical scope. (Yeah, you have to put any parameters in the ->($var1, $var2); part for this to scale.)

Re^4: no chunk is too small
by BrowserUk (Patriarch) on Nov 13, 2005 at 23:58 UTC

    I agree. If the variable used as the loop variable is a pre-existing variable and my is not used, it should not be localised and retain is final value after the loop body.


    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".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Do you want to tell even more people “don’t forget to localise $_” than already get bitten because while(<>) does not localise it?

      I suppose there could be an exception either for $_ or for all global variables, but wouldn’t that be overdoing it a little?

      Makeshifts last the longest.

        I suppose there could be an exception either for $_ or for all global variables, but wouldn’t that be overdoing it a little?

        Actually, I don't think it would be over doing it. If the special case were limited to $_, that wouldn't bother me as I only use non-lexicals where the Perl forces me to, and $_ has plenty of magic associated with it anyway.

        In reality, this could be viewed as the removal of an existing special case, or at leasts it limitation to a smaller range of variables that are affected by that special case.

        Whilst I realise that it is unlikely to change at this point in the life of Perl5 due to the sacred cow of backwards compatibility--there is undoubtedly some code out there that relies upon the current behaviour that would break--I really do hope that it changes for Perl6.

        I can't think of any other situation where an existing lexical is automagically localised?

        As far as I recall, in every other language I used, the retention of the last value by non-locally scoped iterator variables is a given, and a very useful feature. I've used it a lot in parsers, where an index into a buffer is moved along it by successive for and while loops, as the buffer is deconstructed.

        I guess it is slightly different in Perl's case because of the aliasing nature of iterator variables. Having two variables names pointing to the same value space outside of an aliasing construct would be a break with tradition, though if you look at the number of modules that exist to provide exactly this, it seems that it would be a useful feature in many peoples eyes.

        In the end, it's only my opinion, and that isn't going to change anything, but having been bitten by the difference between my expectations and the reality several times, this is one piece of magic that doesn't DWIM for me.


        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".
        In the absence of evidence, opinion is indistinguishable from prejudice.