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

The context around &return_value differs.

Other than its memory space and the time taken to create it, what concerns you about the lvalue? Unless there is more I wouldn't call this a side-effect, as many things are implemented with intermediate lvalues. Am I missing something?

Having not talked much about 'lvalues' it is possible that my usage is baroque. I'd say altering a named value inadvertently is a side-effect. Your usage just seems extremely strict: like saying creating $main::val has the side-effect of creating a whole typeglob. Is this type of usage common? I see its correctness and how compiler writers would use it as I understand your usage here.

I agree with your preference, but I have never used or seen the do2dollar_ for ($var); constructions you have been talking about. I dislike assigning $stuff as the last operation. It just doesn't read well, the invisible $_ seems much better used in the second version. So again I ask, what are the reasons for your preference?

I am going to read this thread to find out more about this usage of for. My first reaction is suspection but I also like a less indented style of coding. 

#!/usr/bin/perl -w
use strict;

sub return_value {
        return ""  unless wantarray;
        return ("this is a value", "xxx", "yyy", "zzz") ;
};

my $stuff;
for ( return_value() ) {
    chomp;
    s/foo//g;
    tr/x/y/;
    $stuff = $_;
}
print "\$stuff >$stuff<\n";

$stuff = return_value();
for ($stuff) {
    chomp;
    s/foo//g;
    tr/x/y/;
}
print "\$stuff >$stuff<\n";

# the output
__DATA__
$stuff >zzz<
$stuff ><

[download]

Replies are listed 'Best First'.
Re^8: Using $_ as a temp var, especially in functions
by Aristotle (Chancellor) on Oct 24, 2002 at 21:57 UTC
    Ahh, silly me, I forgot context. So my examples would have to be either 
    my $stuff;
for(scalar something()) {
    # ...
    $stuff = $_;
}

    [download]
    vs 
    my $stuff = something();
for($stuff) {
    # ...
}

    [download]
    or 
    my $stuff;
for(something()) {
    # ...
    $stuff = $_;
}

    [download]
    vs 
    my ($stuff) = something();
for($stuff) {
    # ...
}

    [download]

    Thanks for the correction.

    For an example on Lvalues, see Abigail-II's inside out objects technique. In retrospect, it seems silly to even field that argument, since a function returning an Lvalue is intent on having it changed.

    What I dislike about the bad forms is that a) it's not obvious that for is being used as a topicalizer rather than loop, unless you know the function in question, and b) if that function is for some reason ever changed to return additional elements, the "topicalizer" will turn into a loop and save the results from modifying the new return value element. Unless of course, you are using the variant which has scalar thrown in, but how likely is that?

    In general I strive to write as self explanatory and easily readable code as possible, assuming the reader has a firm grasp of Perl. It is one of Perl's unique advantages (at least, the degree to which it's possible) that it lets you choose just how much red tape you want. In the terminology of Mark-Jason Dominus' second Program Repair Shop article: I try to minimize the amount of artificial code. At the same time I try to write the natural, essential code verbosely, straightforwardly, without obscure hacks and shortcuts. Well laid out data structures help this, another instance where I can get by with minimal red tape in Perl.

    In that spirit, reason A is my big complaint. A topicalizing for should be clearly obvious as such.

    Makeshifts last the longest.

[reply]
[d/l]
[select]

In Section Meditations