apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject RE: Renames Pending.
Date Wed, 30 Oct 2002 13:36:43 GMT

The APR API sounds like is was created by Yoda; every command ends in a verb.
"Fooled you I did, hummm?" :-)

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

Leave um alone.

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

+1

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


-0. I would prefer to leave them alone (yadda yadda yadda).

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

-1 leave them alone.

>
> >apr_socket_file_create           from apr_socket_from_file
>
> Hmmm.  What is it creating?  How?  This name is pretty ambigious.

-1. Leave it as it is.

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

+1

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

-1

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

Bill


Mime
View raw message