Re^13: Order in which grep/map receive elements

[BrowserUk]

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.

[tobyink]

"The module takes no action -- beyond using grep -- in order to enforce the ordering"

In the interests of nitpicking, I imagine most people using List::MoreUtils will be using the XS version of the module. This is implemented using a for loop in C, which does operate in a defined and documented order.

[BrowserUk]

In the interests of nitpicking,

I'm not sure how interesting nitpicking is ;), but if we're going that route ...

implemented using a for loop in C, which does operate in a defined and documented order.

It uses the for loop to pick values off the stack, and return qualifying results to the stack, which then get return to the caller in the stacked order.

Which is no different to what grep does. Albeit that the iteration is split between pp_grepwhile() in pphot.c and pp_grepstart() in pp_ctrl.c.

In the end, it is the fact that the list out is derived -- in sequence -- from the list in, that defines the ordering in both cases.

[abufct]

As I pointed out back up here -- the docs give a statement of the current reality; not a guarantee!

Wow, I didn't get your point then.
I am sorry, is that _your_ opinion, or well known fact (like the one that grep processes elements consequently)?
When I read std::vector docs (C++) and it says that "vector containers have their elements stored in contiguous storage locations", or that accessing elements takes constant time, then I know that this is a guarantee. And it's not just implementation or "current reality".

[BrowserUk]

When I read std::vector docs (C++) ...

Even with the docs for a commitee designed, standards backed library like the STL, shit happens. And when it does -- eg. an STL library bug I encountered on the 8th September this year -- we users have to track the bug down in order to report it, and (with luck) in the fullness of time, it might get fixed. But in the interim, we users have to code our way around those bugs until the next release comes available.

Just do a search:std::vector confirmed bug to see how prevalent these are. If your users/customers are going to be happy with -- sorry, can't fix it until the next release (or the one after) of the STL -- then by all means, treat the STL as a black box. If you are prepared to shell out for a priority maintenance contract with your compiler/STL supplier, maybe you can get more prompt action, but at a considerable price.

But with CPAN libraries -- and even Perl itself -- you are talking volunteers, mostly hobbyists holding down day jobs, and best-efforts. They'll get to it when they get to it; but only once you have provided a very clear demonstration of the bug -- and preferably a patch. And that means getting your hands dirty and pitching in. And that means every library, and all its dependencies become a part of your code-base for teh purposes of bug discovery and fixing.

Many of the CPAN authors are highly skilled guys who take great pride in their hobby and maintain their modules as if they were their own homes -- sometimes better :).

But there are also many less well written and maintained packages, where the original authors have long since moved on to other projects, languages and work roles. Some of them are dead. Sometimes -- with the more well used, better designed modules, another volunteer will step into the breach and will -- whether through choice or necessity -- pick up the maintenance role.

But inferring these documents -- and their statements of current reality, or even intent -- to give "guarantees" is to guarantee only disappointment and worse.

Given the current author/maintainer of List::MoreUtils, I have little doubt that any bug that arose would be corrected ASAP. But the same is true of Perl itself. And any change in the output ordering of grep would absolutely be classed as a bug; regardless of whether anyone has thought to state the reality of that ordering in the docs or not.