>> 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. > > > Sounds good to me. It makes the API so much simpler to use. > > I just thought that since it's similar to read() it could behave like one. > > I find it strange that you need the pool to allocate the unknown len, > but you don't need one to allocate a certain amount of bytes. To make > the API consistent I'd suggest it to be: > > my $data = $bb->flatten($p, [$len]); > > i.e. always pass $p, and use apr_pcalloc to allocate $len bytes if that > optional argument is passed.
done. take a look when you get the chance just to make sure I did the allocation properly. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
