I'm asking what he uses and what are his reasons, but that may very well be his answer. If he had answered what you answered, I would have pointed out three things.
First, I would have pointed out that his answer conflicts with what he's said so far. He said his choice of keyword is based on the section in which the form is documented, yet there is no documentation that covers this form. (The docs for foreach loops claim to talk about loops that create "a list value".)
Secondly, I would have pointed out that I find very unfortunate that some people pretend that Perl counting loops are foreach loops. Worse yet, they pretend there's some self-evident reasoning that it should be that way. It fools people into wanting to use C-style loop in some attempt to grab performance. (When I thought for (X..Y) was a foreach loop, I didn't use it.) It also fools people into making style arguments based on the incorrect proposition that Perl only has two for loop implementations.
Finally, I would have pointed that I find silly that the driving force behind the choice syntax is to differentiate nothing more than the syntax, especially when it differs from function and efficiency. It seems to me that everyone eventually realises that the redundant syntax clue is completely useless and that they've been forcing themselves to type more than required for nothing.
which is what it acts like.
It doesn't act like a foreach loop. Many people avoid it because they think it does.
| [reply]
[d/l] |
You claim that there is no documentation that covers this form. But perlop documents its existence quite clearly. The same place also clearly documents that you should expect no surprising language semantics from the existence of the optimized version. If you know what the loop is supposed to do, it will still do that. Just using less memory than you thought it would.
However even if you're unaware of that documentation, it should be irrelevant. Any program that ran before it existed will run after, and should give the same output.
As for people who micro-optimize the wrong way without benchmarking, what can I say? My philosophy has been to make things clean and not worry about performance until I have to. So while I'm pleased by the optimization, it doesn't change my default coding style at all.
On the style difference, there is no point in having that argument with me. I always spell it "for". Anyone who has to deal with Perl code in the while will encounter that spelling, and I see no significant benefit in avoiding it. Sure, if you are training beginners in a code base that is careful to always spell them differently, there could be a small learning benefit. (I'm not saying that there is, just that there could be. I have no data either way.) But you're doing your newbies no great favors, and it will annoy experienced people. I would follow such a style rule, but I would dislike it.
However if you were having the argument with me, I wouldn't think that the existence of a minor optimization that programmers are not supposed to be aware of would change my opinion. And, in fact, I believe that your discussion was going in circles in part because I doubt that Argel knew about the optimization. Therefore you were drawing an apparently arbitrary distinction between two different examples of the list form.
| [reply] |
| [reply] |
I'm sorry I did not get what you were asking. I just thought you were asking what I would use if I generated the index values in a Perlish way instead of a C-stylish way. Wasn't thinking about the optimization at all. It's been over six years since I used the range operator in a loop (or outside of one for that matter). And with the smart operator in Perl 5.10+ there's even less reason to use it because I usually work off of hashes or arrays with data that I can loop over. So Tilly has it right.
Elda Taluta; Sarks Sark; Ark Arks
| [reply] |