in reply to Re^12: Order in which grep/map receive elements
in thread Order in which grep/map receive elements
No. Library is a black box. I don't have to maintain its code.
Until it goes wrong. To believe otherwise is naive to the point of ostrichism.
I did not infer that guarantee. It is directly stated in the lib's interface.
As I pointed out back up here -- the docs give a statement of the current reality; not a guarantee!
If you doubt that, consider the implications of clause 10 of the Artistic licence under which the module is distributed:
10. THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
As opposed to grep which has nothing similar in its doc
List::MoreUtils::uniq() can make its statement of reality, because it is known that grep behaves that way.
The module takes no action -- beyond using grep -- in order to enforce the ordering; nor does it do any tests to verify that ordering.
If grep's output ordering changed, then so would List::MoreUtils::uniq(), and believing that when your code that relies upon that ordering starts to fail, it will magically get corrected without any maintenance effort by you, is not just naive, but bloody-mindedly self-delusional.
We're done now.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^14: Order in which grep/map receive elements
by tobyink (Canon) on Oct 08, 2012 at 22:18 UTC | |
by BrowserUk (Patriarch) on Oct 08, 2012 at 23:03 UTC | |
Re^14: Order in which grep/map receive elements
by abufct (Initiate) on Oct 09, 2012 at 06:51 UTC | |
by BrowserUk (Patriarch) on Oct 09, 2012 at 08:03 UTC |