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

[abufct]

Basing correctness on current reality is definitely a bad idea. This leads to programs that can be compiled correctly with specific compiler version only, and programs that require specific version of runtime up to its minor version.
If lots of people and code rely on that reality, then yes, maybe I can rely on it as well. That kind of answer would satisfy me. Several people answered my question and independently said that grep should work like that, so I am more confident in that now.

What would you do if the author(s) decided "if its good enough for Perl, its good enough for us"?

I don't know. If I were the author, I'd try to fix my lib, so that it worked like stated in the docs.

[BrowserUk]

If I were the author, I'd try to fix my lib,

If you wrapped the code you posted in a function and used it, you would be the author.

And would not be reliant upon the good will; the agreement (or not) with you; motivation and timeliness; or continued existence; of some stranger you've never met.

Or worse those same attributes of the latest maintainer, who may decide to take the module in a completely different direction. Something that has happened to me at least 4 times in the last 5 years.

[abufct]

If you wrapped the code you posted in a function and used it, you would be the author.

then i would make my code bigger (and hence harder to maintain) without reason. the maintainer would need to read the code of my function, while he might be familiar with wide-spread library already. i do not like to add to this world's entropy. :-)

Or worse those same attributes of the latest maintainer, who may decide to take the module in a completely different direction. Something that has happened to me at least 4 times in the last 5 years.

Sounds quite sad. Why have such large amount of libs if you are afraid to use them? Maybe you're right and I will change my mind when I use perl for more time.

[BrowserUk]

then i would make my code bigger (and hence harder to maintain) without reason.

Sorry, but that is a crock. Ie. a spurious justifiction.

Whenever you use a library, you add its entirety to your codebase. If you get a bug as a result of a maintenance change in that library, or interaction between a change in your application(s) and that library, it is you that will have to track it down; as often as not it is you that will have to provide a patch before it will get fixed; and in the interim, it is you that will need to provide a workaround in your application to get past it -- even if that just means reverting to an older release; and adding code to detect if your users have the newer breaking version installed.

And not just its functions you use either. But also all of its functions you do not use and all of their dependencies. In the case of List::MoreUtils that includes these 40 modules; not to mention the C compiler and all of its libraries, tools and other paraphernalia.

Sounds quite sad. Why have such large amount of libs if you are afraid to use them?

I'm not afraid to use them; nor am I advocating that you should not. I'm not afraid, because I do not infer guarantees where none exists.

CPAN modules are peoples best-efforts developments, freely shared with us on a "if its useful, use it" basis. Only.

My caution to you is against inferring guarantees were none exist and then basing your development and maintenance strategy upon that.

Your own five-line function -- derived from tested code in a well used module -- is far less risk of becoming a maintenance problem in both the short and long term; than the near 2000 lines of code you need to add to your codebase in order to use those 3 lines that you need from List::Moreutils.

That is still not advocation for you not to use the module; just do so for the right reasons; not wholly specious ones.