apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: Renames Pending.
Date Wed, 30 Oct 2002 13:20:05 GMT
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.

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.

>apr_filepath_name_get           from apr_filename_of_pathname

compliments other apr_filepath names... cool,

>apr_gid_get                     from apr_get_groupid
>apr_gid_name_get                from apr_get_groupname
>apr_gid_name_get                from apr_group_name_get
>apr_gid_compare                 from apr_compare_groups

These operate on apr_gid_t so cool

>apr_socket_shutdown              from apr_shutdown
>apr_socket_bind                  from apr_bind
>apr_socket_listen                from apr_listen
>apr_socket_accept                from apr_accept
>apr_socket_connect               from apr_connect
>apr_socket_send                  from apr_send
>apr_socket_sendv                 from apr_sendv
>apr_socket_sendto                from apr_sendto
>apr_socket_recvfrom              from apr_recvfrom
>apr_socket_sendfile              from apr_sendfile
>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

>apr_socket_filter_accept         from apr_socket_accept_filter

This is in the apr_socket_accept family, why rearrange order here?

>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?

>apr_socket_file_create           from apr_socket_from_file

Hmmm.  What is it creating?  How?  This name is pretty ambigious.

>apr_socket_inherit_set           from apr_socket_set_inherit
>apr_socket_inherit_unset         from apr_socket_unset_inherit

Oh yea!  Thought we had already axed those.

>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.

>apr_uid_homepath_get            from apr_get_home_directory
>apr_uid_get                     from apr_get_userid
>apr_uid_current                 from apr_current_userid
>apr_uid_compare                 from apr_compare_users
>apr_uid_name_get                from apr_get_username

No complaints here.  

View raw message