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

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.

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.

RIP Neil Armstrong

Comment on Re^11: Order in which grep/map receive elements

Replies are listed 'Best First'.
Re^12: Order in which grep/map receive elements by abufct (Initiate) on Oct 08, 2012 at 20:05 UTC
Whenever you use a library, you add its entirety to your codebase. No. Library is a black box. I don't have to maintain its code. New developer does not have read its code and understand how it works. I only add its interface to the codebase. My caution to you is against inferring guarantees were none exist and then basing your development and maintenance strategy upon that. I did not infer that guarantee. It is directly stated in the lib's interface. As opposed to grep which has nothing similar in its doc and I have to infer guarantee from the fact that lots of people use that undocumented feature of grep.	[reply]
Re^13: Order in which grep/map receive elements by BrowserUk (Patriarch) on Oct 08, 2012 at 20:43 UTC
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. 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. RIP Neil Armstrong	[reply] [d/l] [select]
Re^14: Order in which grep/map receive elements by tobyink (Canon) on Oct 08, 2012 at 22:18 UTC
"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. `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply] [d/l]
Re^15: Order in which grep/map receive elements 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
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".	[reply]
Re^15: Order in which grep/map receive elements by BrowserUk (Patriarch) on Oct 09, 2012 at 08:03 UTC


Keep It Simple, Stupid
	PerlMonks