in reply to (Ovid) RE(2): modify variable on pass by value
in thread modify variable on pass by value

I'm not talking about efficiency. I'm talking about natural flow in programming. Every time I have to stop to use a foreach loop because a map wouldn't work, I have to create temporary variables, think of reasonable names for them, and then document them, and ensure their scope is large enough but not too large.

Don't get me wrong. I'm not an FP fascist. But most of the time, temporary values forced on me by the syntax just seems awkward.

Let's go back to this remove-cap function. In a return-value situation, I can use it like this:

my @data = map { RemoveCaps $_ } @input;
Whereas in a act-on-arguments mode, I've got to write this:
my @data = map { my $x = $_; RemoveCaps $x; $x } @input;
I can't use $_ directly, because it would attempt to alter @input (see the other thread on that {grin}). So now I have to invent a stand-in, just so I can act on it.

Just one guy's opinion from someone who's been coding for 30+ years.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
RE: RE: (Ovid) RE(2): modify variable on pass by value
by cwest (Friar) on Sep 11, 2000 at 20:45 UTC
    It seems that the author of the question wants symantics that are like chop. People know what chop is going to do to their variable. If the user is well aware of the way the subroutine will work, is it all that bad? Since you would have to do that with chop anyway?

    Just one guy making conversation with someone who's been coding for 30+ years (honest). {grin}

    --
    Casey
    
      Funny you should bring up chop again.

      In the classes I teach, the fact that chop acts on its arguments is one of the most difficult things for students to keep straight. I see people writing all the time:

      $a = chop $a;
      It's precisely because chop is so different from the rest of Perl that people get it wrong. So I'm not in favor of encouraging people to write more things like chop.

      -- Randal L. Schwartz, Perl hacker

        That surprises me a little. I'd assume people would have more trouble with that because the addition and assignment statement appears to violate algebraic rules:

        $a = $a + $b;

        Obviously Larry's thought about that before, which is why we have:

        $a += $b;

        instead. Once they wrap their heads around the former, the inconsistency of chop trips them up again? Interesting.

(Ovid - Synthetic code) R(4): modify variable on pass by value
by Ovid (Cardinal) on Sep 11, 2000 at 22:55 UTC
RE: RE: (Ovid) RE(2): modify variable on pass by value
by merlyn (Sage) on Sep 12, 2000 at 21:12 UTC