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.
Well, I have used the wrong term. A List is a series of ordered elements. An Array, in Perl, is a variable that contains a List, but a List is not necessarily always an Array. This: (1,2,3) is a List but its not an Array variable.
Sorry about that, I didn't meant to confuse anyone.
Thank you jwkrahn for pointing it out!
There are no stupid questions, but there are a lot of inquisitive idiots.
uniq is self describing, check. That it documents this is a bonus, but it kind of falls out of the fact that grep is implicitly documented this way. As in, when order isn't going to come out the same way, it's documented that it won't, otherwise assume it will. And needing a module is not an issue.
grep, on the other hand, is not "unobvious". The behaviour won't change in future versions of perl. It can't change. The perl devs care way too much about backward compatibility, so it can't change. And the auxiliary variable is self-scoped. Again, not an issue.
So, to me, uniq barely eeks out a win simply on self-describing. Which is why I use it.
Though you missed one point: because List::MoreUtils also comes with XS-based implementations, it can also be faster than using grep. This might matter to you. It doesn't matter to me, so it doesn't make my list of pros, but if it matters to you, you can add that as a plus. Assuming that it was compiled - I've never seen it not compiled, but presumably there may be situations where it isn't.
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.
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).
That is one of the most convoluted pieces of non-reasoning I've seen in a while.
Firstly, assuming that grep will (or even might) suddenly change in a breaking and completely illogical way is like allowing for the possibility that the Sun might rise in the West tomorrow. A theoretical possibility, but distinctly unlikely.
And even if grep did change; basing the correctness of your program on taking the statement that "The order of elements in the returned list is the same as in LIST.", as a guarantee, rather than just a statement of current reality, is naive in the extreme. What would you do if the author(s) decided "if its good enough for Perl, its good enough for us"? Sue.
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 ...
The logic of putting common code in a subroutine -- the DRY principle -- is sound; but just as easily addressed by wrapping your posted code in a subroutine as it is by using a module.
Using List::MoreUtils::uniq() is a perfectly valid choice for any of several reasons, but on the basis of some inferred guarantee, isn't one of them.
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.