in reply to Re^4: "advanced" Perl functions and maintainability
in thread "advanced" Perl functions and maintainability

Then why even bother with map to begin with? And no, that isn't as clear. Go back and look at Brian's example. All map blocks need to be evaluated for each element in the list, so when you have a multi-statement block, you end up putting the result at the end, all by itself:

  map {
     ...

     $hash;
  } ...;

[download]

to make sure the block is evaluated properly. This is a side-effect, and it isn't as clear or as readable as an explicit push would be.

Replies are listed 'Best First'.
Re^6: "advanced" Perl functions and maintainability
by Anonymous Monk on Dec 13, 2004 at 13:49 UTC
    Then why even bother with map to begin with?
    Why not? Some people bother with foreach, one could question that as well.
    And no, that isn't as clear.
    Once again, what's clear and what isn't is highly subjective, heavily influenced by ones experience.
    All map blocks need to be evaluated for each element in the list,
    Uhm, yes. That's the point of a map, isn't? And perhaps you haven't realized it, all foreach blocks are evaluated for each element of the list as well.
    you end up putting the result at the end, all by itself:
    Yeah, neat, isn't? That's the point of map, you know.
    This is a side-effect, and it isn't as clear or as readable as an explicit push would be.
    Actually, it's not a side-effect. Modifying a variable (what push does) is a side-effect.

    But I understand what you are saying. It's utterly unclear to write a map this way. After all, it's also unclear to return a result from a subroutine; it's much clearer if the subroutine explicitly assigns the return value to a variable. All well written programs do.

[reply]

      Uhm, yes. That's the point of a map, isn't? And perhaps you haven't realized it, all foreach blocks are evaluated for each element of the list as well.

      I'm referring to how map takes the result, the final statement, of each block and passes it on to the resulting list. Judging by your next statement, you understood perfectly what I was saying but still choose to be smartass anyway:

      Yeah, neat, isn't? That's the point of map, you know.

      But I understand what you are saying. It's utterly unclear to write a map this way. After all, it's also unclear to return a result from a subroutine; it's much clearer if the subroutine explicitly assigns the return value to a variable. All well written programs do.

      Nice contrived example to try to prove your point. The subroutine equivalent would be leaving off the return statement and letting the last statement implicitly be the return value:

      sub ringForward {
    ...

    $modem->send($tone, $duration);
}

sub ringForward {
    ...

    return $modem->send($tone, $duration);
}

      [download]

      But I guess one is just as clear as the other, right? You can easily tell whether or not you can check the return value just from looking at either one, right?

[reply]
[d/l]
        The subroutine equivalent would be leaving off the return statement and letting the last statement implicitly be the return value
        People write code that does that all the time.

        You can easily tell whether or not you can check the return value just from looking at either one, right?
        I don't understand that final question. Are you suggesting there is a difference in both functions?
[reply]
        A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Meditations