Re^9: "advanced" Perl functions and maintainability

[William G. Davis]

Well, you were the one claiming they shouldn't use m// because that's more work for perl than using index, posting a benchmark to back up your claim.

No, I didn't. You're putting words in my mouth. I claimed that many Perl hackers use m// exclusively, regardless of efficiency, then I posted bechmarks showing that, for constant substrings, index/rindex are usually faster.

I posted a benchmark using different data which shows index losing. index *isn't* always faster, so Perl hackers aren't "wrong" or even inefficient for using m// over index.

I never claimed it was "always" faster or that people were wrong to use m//. diotalevi tried to use efficiency as a reason to choose map instead of foreach, and I pointed out that most Perl hackers use m// regardless of its efficiency. Some never touch index/rindex. The fact is that efficiency is the last thing on their mind when they make their choice. map and m// generally take less typing, and, I guess, are much cooler, and that's the reason why so many Perl hackers live and die by them.

Yes I did. If you think I'm wrong, please point out an unquated meta character in one of the pattern strings. If there were unquoted meta characters in the pattern strings, the benchmark wouldn't be fair, would it? index doesn't know metacharacters.

If the scalar containing the substring to search for comes from some extenral source (e.g., supplied to your function as an argument), then you'd have to quote metacharacters in it anyway, which is usaully the only reason why I'd put a scalar inside of a pattern to begin with. Although I guess for this example you could just do away with the scalar altogether and put its contents directly in the pattern.

[diotalevi]

Efficiency still is a reason to prefer map->assign over foreach(push). In the case of m// over index, its a case of allowing your needs to grow easily. When I use index I'm making a bet that I will only want to do exact string comparisons. That's frequently not the case over the long run so for that case, the decision often tilts toward m//.

Again, the code isn't written to be instructional to a novice. It is written to be usable by competent perl programmers. I don't much care if a C or VB programmer doesn't understand it right away. That is, assuming the code is in a place that I don't expect novice programmers to be. If I have the expectation that someone with lowered abilities to read perl is going to need to understand it, I will write in a way that maximizes readability. Often that must means using a few more intermediate variables but I know I've switched from a map->assign to foreach(push) just for that context. It is about what is situationally appropriate. I've no hard and fast rule and I don't expect anyone else to either. I do expect that programmers will let the current priorities guide how they work.

I should also note that while I do try to write in a style that prefers runtime efficiency over reabability by novices, I always try to keep it at a modest level and use as many layout hacks as necessary to make the structure apparent to me or someone of equal ability.