in reply to Re^5: Spot the bug
in thread Spot the bug

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.

Perl --((8:>*

Replies are listed 'Best First'.
Re^7: Spot the bug
by demerphq (Chancellor) on Dec 22, 2005 at 09:12 UTC

    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.


      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?

      Perl --((8:>*

        You missed the point. If you have two subs that open file handles on a the same file they don't need to worry about each other. If however you have two subs that 'open' an each on the same hash, you are in serious trouble. I couldn't realy quoute you numbers on the use of either, but filehandles are certainly very different than each.

        Eric Hodges $_='y==QAe=e?y==QG@>@?iy==QVq?f?=a@iG?=QQ=Q?9'; s/(.)/ord($1)-50/eigs;tr/6123457/- \/|\\\_\n/;print;
Re^7: Spot the bug
by shotgunefx (Parson) on Dec 21, 2005 at 19:04 UTC
    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 digital dash (in progress)
      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.

      Perl --((8:>*
        I'm not agaist obvious and useful side effects (that's why I don't program in LISP, though I like some aspects of it).

        Personally, I don't consider your two examples as side effects (even though some would). The effect of warn and assigment is the intended effect. There could be other effects due to magic hanging off them, but that's another story.

        As far as lexically bound, I mean that it seems more intuitive to have the hash iterator block scoped.