in reply to Re^6: Order in which grep/map receive elements
in thread Order in which grep/map receive elements
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.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^8: Order in which grep/map receive elements
by abufct (Initiate) on Oct 06, 2012 at 06:05 UTC | |
by BrowserUk (Patriarch) on Oct 06, 2012 at 06:35 UTC | |
by abufct (Initiate) on Oct 07, 2012 at 10:35 UTC | |
by BrowserUk (Patriarch) on Oct 07, 2012 at 11:29 UTC | |
by abufct (Initiate) on Oct 08, 2012 at 20:05 UTC | |
|