Geoffrey Young wrote:
I don't like this populate-the-argument C interface.


me neither.

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, ...) {}

And we already do
that in several places. But for 2 arguments? That's too much and
inconsistent with other similar interfaces. I think pflatten should be
similar to $r->read(), i.e. populate the buffer $data, but return the
number of bytes it has read.


that probably makes more sense.  but it makes it dissimilar from flatten()
which returns both the data and length as well.

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.


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 ;)

with your implementation $rc is useless
anyway.


well, not useless - if it's not APR::SUCCESS then you know not to use the
returned information

Yes, yes, but you convey that exact information in returning undef vs. defined length.


It should return -1 on error and 0 or more as a number of bytes
populated in $data.


I prefer undef to -1 in a perl interface.

Oops, you are right, then we need to fix the read as well. For some reason I thought perl's read() was returning -1.



__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to