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
