in reply to Re^2: Using $_ as a temp var, especially in functions
in thread Using $_ as a temp var, especially in functions

second snippet isn't aliasing anything

Good point. It would have to be 

$_= 'value before localising';
my $thingToAlias =  'the quick brown fox';
{
    local *_= \$thingToAlias;
    s/brown//;
}
print $thingToAlias;
print $_;

[download]

Giving 

C:\test>test
the quick  fox
value before localising

C:\test>

[download]

A silly example would be s/nit// for $style;

I can't see any advantage in this over $style =~ s/nit//;?

I appreciate this was just a trivial example, but I can't see where this would be useful as a statement modifier? (No doubt you have a great example up your sleeve:^)

For temporary variables, which was what this thread really was about, I use local. Not only does a for block not do what I want anyway (except (close your eyes) in the perverted for(my $temp) { ... } form (now open them again)) because it aliases a variable rather than give me a fresh, empty one, but it also adds another indentation level, which in my stylistic preference is to be avoided at all cost.

for and local are really orthogonal to each other. Neither can do what the other does, and so debating which one is preferred is moot.

Agreed. They are unrelated, but I was responding to Re: Using $_ as a temp var, especially in functions in the second part of my post rather than the OP.

I first saw the 1-time for when you showed it to me in a thread about a week ago (which I can't now find?) but I was uncomfortable with the idiom of using a loop for a straight through peice of code. I'm similarly troubled by the use of redo in a bare block or if statement, prefering to see a loop construct where things are going to loop.

I did spend a while after you first showed me the 1-time for looking for a suitable alternative. And came up with the local *_ = \$variable; (Which in turn was stolen from the Cheap idioms thread.), but promptly forgot the detail as I haven't had a need to use it yet. That's also why I was interested in the arguments against it.

Who knows, maybe in time I'll get used to these idioms as I have others and go with the flow (sic), but as I said, my devlopment of a personal style, and my investigations of what's possible in perl is ongoing.

Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!

Replies are listed 'Best First'.
Re^4: Using $_ as a temp var, especially in functions
by Aristotle (Chancellor) on Oct 24, 2002 at 12:38 UTC
    You are right, that example is silly, which is why I said so. :^) It's useful (as that thread was discussing btw) for something like $_ eq "pot" and ($_ = "kettle") for $some->{deeply}{nested}{data}{structure}; The straight alternative is 
    $some->{deeply}{nested}{data}{structure} = "kettle"
    if $some->{deeply}{nested}{data}{structure} eq "pot";

    [download]
    which irritates my hubris. Localizing here is better than that, but it's just too much red tape for my taste: 
    {
    local *_ = \$some->{deeply}{nested}{data}{structure};
    $_ = "kettle" if $_ eq "pot";
}

    [download]

    local *_ = \$something; is not a language construct, I have to brainparse it and understand what's going on to read the code.

    I see where you object to a loop that has only one iteration, although I find the use of redo in a naked block far worse than a single-iteration for loop: the redo conceils the loop character because you don't know that that naked block is one until you read to an arbitrary point inside it. for used as a topicalizer on the other hand makes it immediately obvious that we're only looking at a single iteration.

    The example you gave where a function's return value is topicalized misses the point. You topicalize a variable when you intend to modify it - doing that to a function return value you haven't saved is pointless. You might of course do something like this:

    my $stuff;
for(return_value()) {
    chomp;
    s/foo//g;
    tr/x/y/;
    $stuff = $_;
}

    [download]
    But if I had to maintain that I'd hunt you down and kill you. That obviously should have been 
    my $stuff = return_value();
for($stuff) {
    chomp;
    s/foo//g;
    tr/x/y/;
}

    [download]

    For the record, I actually don't use the long construct with the for block frequently either. It does come in very handy when it's appropriate though. (I got the idea of using for as a topicalizer from the man himself actually - he mentioned this in an interview, where he said it Perl has a topicalizer, for, which lets people say "it", ie $_, without specifying the subject over and over.)

    That's what I have to say on the issue. YMMV :-)

    Makeshifts last the longest.

[reply]
[d/l]
[select]
      Could you please expand on your thoughts on: 
      my $stuff;
for(return_value()) {
    chomp;
    s/foo//g;
    tr/x/y/;
    $stuff = $_;
}

      [download]
      versus 
      my $stuff = return_value();
for($stuff) {
    chomp;
    s/foo//g;
    tr/x/y/;
}

      [download]
      I agree that the first form is lousy, but since the second snippet is not equivalent I am not sure what you dislike about the first version.
[reply]
[d/l]
[select]
        I'm not sure what difference you are referring to. $stuff will contain the the same value after both snippets, so at least with respect to intent they are equivalent. What I can see is that the first one will have a hidden side effect when return_value() produces an Lvalue - which for me is just another reason to shun that version. Is there something I missed?

        Makeshifts last the longest.

[reply]

In Section Meditations