That is an implementation detail. :-)

Remember, code is written primarily for programmers to read and only incidentally for a machine to execute. Did you profile this and found it to be a problem?

NB: I quarreled with the thought of adding a note to the effect that this construct loops twice on my previous node, but decided against it. The typical data set in this function would consist of one element, or of less than 10 elements in most other cases. Musing about its efficiency therefore seems like a rather pointless excercise.

Musing about its efficiency therefore seems like a rather pointless excercise. </code>

I just don't see the point in looping twice when a single loop will do. Each loop has its overheads regardless of how many elements are involved, so why incur them twice when the readability gain is low? In fact IMO a lot of maintenance programmers won't even know what 'grep' does but will probably guess correctly what 'next if' does. So you aren't really improving readability for the price of a definite efficiency loss.

I've only seen one or two situations where I felt 'for grep' or 'map grep' made much sense. *shrug* :-)



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

Interesting, I have no particular prejudice against such constructs, and find that I use them quite regularly. It all comes down to trying to write optimally-dense code, by which I mean the densest code that I [0] can easily grok at reading pace.

As such, it makes most sense when it reduces the loop action to a simple expression:

  # build the dependency map for active children
  $child{$_} ||= $parent{$_} for grep $_->active, $self->children;
[download]

or:

  warn "Deleting removed script '$_'\n" for map $_->name, @deleted;
[download]

It can also help by letting me put the important information into the name of the loop variable:

  for my $hidden (grep !$_->visible, @objects) {
    ...
  }
[download]

In each of these cases, I think I can grasp the effect and intent of the code quicker than with an alternative that tries to avoid the construct:

  # build the dependency map for active children
  $_->active and $child{$_} ||= $parent{$_} for $self->children;
  # (My brain doesn't grok 'condition and action' as fluently as
  # 'action if condition', but handles 'grep' fine.)

  warn "Deleting removed script '@{[ $_->name ]}'\n" for @deleted;
  # hmm, a minor difference, but @{[ ...]} is just too much punctuatio
+n

  for my $object (@objects) {
    next if $object->visible;
    # below here '$object' is less informative
    ...
  }

  for my $hidden (@objects) {
    # '$hidden' is a lie here
    next if $hidden->visible;
    ...
  }
[download]

(Examples all taken from my work application, with minor edits.)

Hugo

[0] That is, myself or any suitable qualified other programmer who might look at my code in the future. My work code is not intended to be maintained by someone that doesn't know perl, and so isn't aimed to be readable for such a person.