William A. Rowe, Jr. wrote:


If the filesystem doesn't handle it, I fail to see what benefit we get from
displaying it.

But that's not the point. My point was that I cannot see from the name strfsize that this function is tied to filesystem limits. why not call it apr_file_strfsize? And let apr_strfsize accept bigger values without any relation to filesystem limits.

e.g. I want to use strfsize to count money :)


fsize is filesize plain and simple :) So rename it appropriately as I pointed out below.


really? I read it as string_format_size, the same as strftime stands for string_format_time.

Now I understand the source of my confusion, but boy, this is so not obvious. I still think apr_file_strsize is a much better name.


Unless you want to make apr_strfsize into something more generic, such as
apr_format_brief_size_binary(), taking the hugest int we can pass it, and returning a binary metric NNNNm where m is a magnitude. There wouldn't
be any harm in that, someone could extend it to apr_format_brief_size_metric()
for true decimal representations. But apr_strfsize sure sounds like a filesystem API here :)


why stopping at int?


Exactly, apr_int64_t sounds reasonable. If you want an implementation that takes a double, I'd ask that you make that a second function.

no prob. what should be the name then? apr_str_fmt_size

since APR keeps on growing it'd be very nice to try hard to maintain "virtual" namespaces for most of the functions so you always have two top namespace levels before you reach the function name.

so apr_file_ is the namespace for files related functions, therefore with common sense applied, apr_strfsize should be there, like in apr_file_strsize.

If we are talking about general purpose string manipulation function it should probably live in apr_str_ namespace, like apr_str_fmt_size.


_____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/



Reply via email to