Re^5: Spot the bug

[tlm]

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.

[Perl Mouse]

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.

[shotgunefx]

I think it would be better to bind lexically to the value myself. Having some code you pulled in cause side effects is definitely not what most people think of as DWIW.

I started to try and address this issue with RFC Magic::Attach some time ago, but it fell by the way side due to outside obligations.

[Perl Mouse]

I think it would be better to bind lexically to the value myself.

What does "bind lexically to the value" mean?

Having some code you pulled in cause side effects is definitely not what most people think of as DWIW.

Well, perhaps not in a language like LISP or Haskell, but it's pretty hard to do something in Perl that doesn't have side-effects. Even looking at a value can change it (and hence, is a side-effect). Assignment is a side-effect. warn is a side-effect. Processing @ARGV is a side-effect. Reading from a handle is a side-effect.

People don't actually mind side-effects. In fact, most people will expect side-effects. What people don't like is unexpected side-effects. But I never advocated not telling what code does.

[demerphq]

I dont think its fair to equate each(%hash) and filehandles, the reason being that I can have multiple filehandles open on the same file without any interference problems. But with each, you have to always consider that any traversal of the hash has to be completely independent. Thus a routine that takes a filename and traverses the file calling out a callback to process each chunk is totally safe. The equivelent routine that takes a hash and traverses it using each calling out to a callback runs the serious risk that the hashes iterator will be reset or changed by user code.

I can think of all kinds of behaviour that is totally safe with filehandles and is not safe with each(%hash). They just aren't the same thing.

[Perl Mouse]

But Perl doesn't have a 'file' as datatype. Perl has filehandles. Just like it has hashes. You can have multiple filehandles, and actions on them don't interfere. You can have multiple hashes, and actions on them don't interfere either.

And while it's true that you can open multiple handles to the same file, when was the last time you saw a program opening multiple handles on STDIN or on a socket, to name a few common streams programs read from?