* On Tue, May 11 2010, Klaus wrote:
> However, unlike XML::Twig, XML::Reader does not rely on callback
> functions to parse the XML. With XML::Reader you loop over the
> XML-document yourself and the resulting XML-elements (and/or
> XML-subtrees) are represented in text format. This style of processing
> XML is similar to the classic pattern:
>
> "open my $fh, '<', 'file.txt'; while (<$fh>) { do_sth($_); } close $fh;"
FWIW, it's very easy to make callback-based code look like an iterator.
Here's an example script.
use strict;
use warnings;
use feature ':5.10';
use Coro;
use Coro::Handle;
use Coro::Channel;
Imagine you have a routine that calls a callback for each event, like
receiving a line from a filehandle:
sub call_on_line(&){
my $cb = shift;
async {
my $fh = unblock \*STDIN;
while(my $line = $fh->readline){
chomp $line;
$cb->($line);
}
};
}
(Ignore the implementation here, it's just an example.)
You can "loop over" the results of the callback, like this:
my $chan = Coro::Channel->new;
call_on_line { $chan->put(@_) };
async {
while(my $item = $chan->get) {
say "GOT ITEM: $item";
}
}->join;
So I'm not sure there's a point in writing a module just to be
loop-driven instead of callback-driven; it's easy to convert
callback-based code to "blocking" code.
When in doubt, if you are trying to write something reusable, make it
callback-driven instead of blocking. Then the consumer can easily
choose how to use it.
Regards,
Jonathan Rockway
--
print just => another => perl => hacker => if $,=$"
