in reply to Re^2: Order in which grep/map receive elements
in thread Order in which grep/map receive elements

Probably because it is considered too obvious require documentation.

Things come out of map/grep in the same order they went in.

With the single exception of when grep removes item(s) from the stream, in which case those things that do come out, do so in the same relative ordering with which they went in.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong
  • Comment on Re^3: Order in which grep/map receive elements

Replies are listed 'Best First'.
Re^4: Order in which grep/map receive elements
by abufct (Novice) on Oct 05, 2012 at 12:39 UTC
    ok, thanks a lot! i've decided to use List::MoreUtils 'uniq', which explicitly states what I want (and uses exactly the same code I've cited in my first post).
[reply]

      BrowserUk is right, don't use a module to do that if you can do it with one line of code! Grep receives an array a LIST and returns an array a LIST. The returned array will be shorter, but the elements will be added in the order in which they are encountered in the other array.

      Imagine you do this: 

      @array1 = @array2;

      [download]
      The elements in @array1 will be in the same order has in @array2, right?

      Now do this: 

      foreach $element ( @array2 ) {

  push( @array1, $element );
}

      [download]
      The elements in @array1 will still be in the same order has in @array2, don't you think?

      And if you do this: 

      foreach $element ( @array2 ) {

  if ( not $seen{$element} ++ ) {
    push( @array1, $element );
  }
}

      [download]
      Guess what? The elements will still be in the same order and I just explicitly did what grep do in one line.

      There are no stupid questions, but there are a lot of inquisitive idiots.
      -- greengaroo
[reply]
[d/l]
[select]
[reply]

        uniq:
        + self describing code
        + behavior is guaranteed by module docs
        - needs a module (but I have it on our servers already)

        grep:
        - unobvious construct
        - behavior might change in future versions of perl (although that's unlikely)
        - declares auxiliary variable that might interfere with other code

        The choice is quite obvious to me. :-)

[reply]

      Hm So you'll use the module in preference to the code you posted because it explicitly states ordering, despite knowing that it uses exactly the same code.

      Erm. O-kay.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      RIP Neil Armstrong
[reply]
        Yes. If (when) this code stops working because of changes in perl, there will be a bug in the library. And this bug will be fixed (in a single place). I won't have to go through all my code and find all appearances of this code and fix it. I'd write my own function for that if I didn't have that module installed on our servers already.
[reply]

In Section Seekers of Perl Wisdom