Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^5: Spot the bug

by tlm (Prior)
on Dec 21, 2005 at 16:51 UTC ( [id://518344]=note: print w/replies, xml ) Need Help??


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

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.

the lowliest monk

Replies are listed 'Best First'.
Re^6: Spot the bug
by Perl Mouse (Chaplain) on Dec 21, 2005 at 17:46 UTC
    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:>*

      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.

      ---
      $world=~s/war/peace/g

        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:>*
      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.

      -Lee

      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:>*

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://518344]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2024-03-29 06:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found