The problem is people have a bad habit of forgetting to reset the iterator,
Yes, and? As long as you don't forget it in your general routine (unless you have good reason not to).
heaven help you if the general routine calls back out to uncontrolled code from inside the loop.
Yes, and? Presumably the uncontrolled code was passing in as an argument, one way or the other (otherwise, it wouldn't be uncontrolled). It's the users responsibility, just as it's the users responsibility to not pass in vital files as arguments to unlink.
Iterators hand the programmer some rope, but what doesn't? That's not a reason to avoid iterators all together.
| [reply] |
I think the problem is not with iterators as such, as much as with the fact that the scope and workings of this particular iterator are so non-obvious. In other words, it's the "magic" the bites here, IMO, not the iterator. I posted a hash iterator class some months ago that lets one create multiple simultaneous lexically-scoped iterators on any hash, but somehow it feels like overkill for most situations. Maybe this is a facility that should be built-in.
| [reply] |
The each iterator is not unlike the behaviour of a filehandle where you are reading line by line. Perhaps you find that iterator non-obvious as well, and you prefer to do
my @lines = <$file_handle>;
for my $line (@lines) {
...
}
but I bet people will comment on that if you start promoting that style on Perlmonks.
I find iterators bind to the data they act on far more natural than being binded to the location in the source code. It translates to an OO approach much more naturally.
| [reply]
[d/l] |
