apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thom May <t...@planetarytramp.net>
Subject Re: Renames Pending.
Date Wed, 30 Oct 2002 13:53:22 GMT
* William A. Rowe, Jr. (wrowe@apache.org) wrote :
> At 06:19 AM 10/30/2002, Thom May wrote:
> >Ok, here goes (this is much more practical than the patch):
> 
> Agreed.  However, I have some mixed feedback here.  The long
> and short of it; commit apr_gid and apr_uid changes already,
> and apr_filepath_name_get, but take one last look at socket before 
> committing it.  Perhaps hold off on time.  And absolutely don't commit 
> apr_file_[l]stat just yet for reasons I note below.
> 
sure. I just don't want to see this stuff get thrown out of the 1.0 window
:-) (and I want 1.0 soon) ;-)

> Here's the tour...
> 
> 
> >apr_file_stat              from apr_stat
> >apr_file_lstat             from apr_lstat
> 
> Bah... as discussed, these don't operate on apr_file_t's, they
> don't qualify as apr_file_ operations.  Perhaps as apr_finfo_stat
> etc they could be renamed.
> 
hrm, I must have missed this bit of the last discussion, or my memory is
failing. OK, these are on hold.

> 
> >apr_socket_shutdown              from apr_shutdown
[...]
> >apr_socket_recv                  from apr_recv
> 
> I was about to make the old complaint that these api's are overkill,
> standard names, etc.  And then I considered apr_file_t and it's functions.
> So +1 here, even over those old objections, for each function which
> operates on (has a first argument of) an apr_socket_t.  But there are
> exceptions...

right.
> 
> 
> >apr_socket_filter_accept         from apr_socket_accept_filter
> 
> This is in the apr_socket_accept family, why rearrange order here?
>
good point.
 
> >apr_hostname_get                from apr_gethostname
> >apr_port_addr_parse             from apr_parse_addr_port
> >apr_sockaddr_fromname_set       from apr_getservbyname
> >apr_sockaddr_hostname_get       from apr_getnameinfo
> 
> Bleh.  Ick.  There isn't consistency here.  These will be difficult
> for coders to recall.  They are a little rough, don't you think?
> 
I kind of agree. the last two are nasty, but consistent, the first one...
ber.
the second one i think is better in the changed form.

> >apr_socket_file_create           from apr_socket_from_file
> 
> Hmmm.  What is it creating?  How?  This name is pretty ambigious.
>
This one is icky. I hate the current name's lack of coherency with anything
else, but I don't know what to call it.
 
> 
> >apr_time_exp_gmt_get            from apr_implode_gmt
> 
> Grumpf.  Another hard to use name... I have to look at the big time
> picture again to see if that's the right solution.
> 
It's in line with the rest of the explode/implode functions now.

Mime
View raw message