> I'd rather see:
>
> my ($data, $len) = foo(...);
>
> so much more perlish. but I guess it's too late in the game.
>
> The only inconvenience is that you can't use that in the while loop:
>
> while (defined my $len = foo($data, ...) {}
> there is no problem here. flatten should accept how much data to read as
> an argument and return how much it actually read as a return value.
> That's exactly how perl's read() works. and that value is optional.
the problem with all of these is that it's breaking away from the 1:1
mapping of the original apr_brigade_(p)flatten APIs. if we're going to do
that to make them more perlish, I'd much rather see
my $data = $bb->flatten(30); # calls apr_brigade_flatten
my $data = $bb->flatten($p); # calls apr_brigade_pflatten
and throw away the length component, since it's very rarely important
anyway, has the possibility of being wrong (at least that's my reading of
the API), and can be computed (more accurately) if required.
>
> Now that you mention that, we could really have one interface instead of
> 2. If you pass the optional read length value it'll use flatten if you
> don't it'll use pflatten. make it use the pool object in both but ignore
> in flatten. So you get a 1:1 mapping to perl's read (we may even support
> the offset argument later on) ;)
>
> Hell, why not write PerlIO::BB ;)
I'm already working on APR::TieBrigade, which lets you manipulate a brigade
like a perl $fh :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
