You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Doug MacEachern <do...@covalent.net> on 2001/02/06 06:21:55 UTC
apr_ function prefixes
there's a number of places where apr (and httpd) is not consistent with
prefixes or doesn't use one at all (beyond apr_ or ap_).
personally, i like to see functions named with the prefix of the base type
(struct) they operate on if possible. for example, apr_xlate_t related
functions all have an apr_xlate_ prefix, this is goodness. for certain
types, many, but not all related functions use a consistent prefix
(e.g. apr_table_t), for some there is no prefix at all.
i know this might be considered "late in the game", but in reality apr is
very young software. consistent/meaningful naming should start now,
rather than 2 years down the road when i suspect it'll be in pretty
widespread use. below are some suggestions, i think i still have a
rename script handy if there's consensus to move forward on some or all.
apr_pollfd_t:
apr_add_poll_socket apr_poll_socket_add
apr_clear_poll_sockets apr_poll_socket_clear
apr_get_polldata apr_poll_data_get
apr_get_revents apr_poll_revents_get
apr_mask_poll_socket apr_poll_socket_mask
apr_remove_poll_socket apr_poll_socket_remove
apr_set_polldata apr_poll_data_set
apr_setup_poll apr_poll_setup
apr_time_t:
apr_now apr_time_now
apr_array_header_t:
apr_append_arrays apr_array_append
apr_copy_array apr_array_copy
apr_copy_array_hdr apr_array_copy_hdr
apr_make_array apr_array_make
apr_push_array apr_array_push
apr_socket_t:
apr_close_socket apr_socket_close
apr_create_socket apr_socket_create
apr_get_sockaddr apr_socket_addr_get
apr_get_socketdata apr_socket_data_get
apr_set_socketdata apr_socket_data_set
apr_sockaddr_t:
apr_getaddrinfo apr_sockaddr_info_get
apr_get_ipaddr apr_sockaddr_ip_get
apr_set_ipaddr apr_sockaddr_ip_set
apr_set_port apr_sockaddr_port_set
apr_get_port apr_sockaddr_port_get
apr_pool_t:
apr_create_pool apr_pool_create
apr_destroy_pool apr_pool_destroy
apr_get_userdata apr_pool_userdata_get
apr_set_userdata apr_pool_userdata_set
apr_kill_cleanup apr_pool_cleanup_kill
apr_run_cleanup apr_pool_cleanup_run
apr_null_cleanup apr_cleanup_null
apr_register_cleanup apr_cleanup_register
apr_make_sub_pool apr_pool_sub_make
apr_note_subprocess apr_pool_note_subprocess
apr_lock_t:
apr_child_init_lock apr_lock_child_init
apr_create_lock apr_lock_create
apr_destroy_lock apr_lock_destroy
apr_get_lockdata apr_lock_data_get
apr_set_lockdata apr_lock_data_set
apr_lock apr_lock_aquire
apr_unlock apr_lock_release
apr_table_:
apr_clear_table apr_table_clear
apr_copy_table apr_table_copy
apr_make_table apr_table_make
apr_overlap_tables apr_table_overlap
apr_overlay_tables apr_table_overlay
apr_file_t:
apr_open apr_file_open
apr_close apr_file_close
apr_create_namedpipe apr_file_namedpipe_create
apr_create_pipe apr_file_pipe_create
apr_dupfile apr_file_dup
apr_flush apr_file_flush
apr_eof apr_file_eof
apr_ferror apr_file_error
apr_fgets apr_file_gets
apr_fprintf apr_file_printf
apr_full_read apr_file_read_file
apr_full_write apr_file_write_full
apr_getc apr_file_getc
apr_ungetc apr_file_ungetc
apr_putc apr_file_putc
apr_puts apr_file_puts
apr_read apr_file_read
apr_write apr_file_write
apr_writev apr_file_writev
apr_seek apr_file_seek
apr_get_filedata apr_file_data_get
apr_getfileinfo apr_file_info_get
apr_get_filename apr_file_name_get
apr_get_file_pool apr_file_pool_get
apr_get_pipe_timeout apr_file_pipe_timeout_get
apr_set_pipe_timeout apr_file_pipe_timeout_set
apr_lock_file apr_file_lock
apr_unlock_file apr_file_unlock
apr_open_stderr apr_file_open_stderr
apr_open_stdout apr_file_open_stderr
apr_remove_file apr_file_remove
apr_rename_file apr_file_rename
apr_set_filedata apr_file_data_set
apr_setfileperms apr_file_perms_set
apr_procattr_t:
apr_createprocattr_init apr_procattr_create
apr_setprocattr_childerr apr_procattr_child_err_set
apr_setprocattr_childin apr_procattr_child_in_set
apr_setprocattr_childout apr_procattr_child_out_set
apr_setprocattr_cmdtype apr_procattr_cmdtype_set
apr_setprocattr_detach apr_procattr_detach_set
apr_setprocattr_dir apr_procattr_dir_set
apr_setprocattr_io apr_procattr_io_set
apr_setprocattr_limit apr_procattr_limit_set
apr_proc_t:
apr_create_process apr_proc_create
apr_fork apr_proc_fork
apr_kill apr_proc_kill
apr_probe_writable_fds apr_proc_probe_writable_fds
apr_reap_other_child apr_proc_other_child_read
apr_register_other_child apr_proc_other_child_register
apr_unregister_other_child apr_proc_other_child_unregister
apr_check_other_child apr_proc_other_child_check
apr_wait_all_procs apr_proc_wait_all_procs
apr_wait_proc apr_proc_wait
apr_detach apr_proc_detach
apr_thread_t:
apr_create_thread apr_thread_create
apr_get_threaddata apr_thread_data_get
apr_set_threaddata apr_thread_data_set
apr_thread_detach apr_thread_detach
apr_threadkey_t:
apr_get_threadkeydata apr_threadkey_data_get
apr_set_threadkeydata apr_threadkey_data_set
apr_create_thread_private apr_threadkey_private_create
apr_delete_thread_private apr_threadkey_private_delete
apr_get_thread_private apr_threadkey_private_get
apr_set_thread_private apr_threadkey_private_set
apr_threadatt_t:
apr_create_threadattr apr_threadattr_create
apr_getthreadattr_detach apr_threadattr_detach_set
apr_setthreadattr_detach apr_threadattr_detach_get
apr_dir_t:
apr_make_dir apr_dir_make
apr_remove_dir apr_dir_remove
apr_uuid_t:
apr_format_uuid apr_uuid_format
apr_get_uuid apr_uuid_parse
apr_parse_uuid apr_uuid_parse
apr_shmem_t:
apr_get_shm_name apr_shm_name_get
apr_set_shm_name apr_shm_name_set
apr_open_shmem apr_shm_open
apr_hash_t:
apr_make_hash apr_hash_make
misc:
apr_getpass apr_password_get
apr_validate_password apr_password_validate
apr_generic_hook_get apr_hook_generic_get
apr_hook_generic apr_hook_generic_add
Re: apr_ function prefixes
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 07, 2001 at 08:57:53PM -0800, B. W. Fitzpatrick wrote:
>
>
> On Wed, 7 Feb 2001, Doug MacEachern wrote:
>
> > to see the files that will change and the line number/name change:
> > http://perl.apache.org/~dougm/apr_rename.txt
>
> +1. Wow that looks great. A toast to consistency!
>
> Is there any way you could forward along the conversion script that you
> used (Or is that the one you sent last week)? This is going to break
> Subversion a bit, and maybe I (or Greg) can get those changes in and
> committed first thing in the morning.
I'm on it now... ;-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
Posted by Jeff Trawick <tr...@bellsouth.net>.
Jeff Trawick <tr...@bellsouth.net> writes:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
> > on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put
> > and apr_os_thread_put. i assume that's wrong, since i can't for the
> > life of me figure out what pupt would mean ;-)
>
> good for you
>
> if sleeping child cooperates I'll fix it up Real Soon Now...
well, all I got was cvs not-up-to-date messages :) mailing list
delays are no fun...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: apr_ function prefixes
Posted by Jeff Trawick <tr...@bellsouth.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put
> and apr_os_thread_put. i assume that's wrong, since i can't for the
> life of me figure out what pupt would mean ;-)
good for you
if sleeping child cooperates I'll fix it up Real Soon Now...
$ grep pupt `find . -name '*.h'`
./srclib/apr/include/apr_portable.h: * @deffunc apr_status_t apr_os_exp_time_pupt(apr_exploded_time_t
*aprtime, apr_os_exp_time_t **ostime, apr_pool_t *cont)
./srclib/apr/include/apr_portable.h:APR_DECLARE(apr_status_t) apr_os_exp_time_pupt(apr_exploded_time_t *aprtime,
./srclib/apr/include/apr_portable.h: * @deffunc apr_status_t apr_os_thread_pupt(apr_thread_t **thd, apr_os_thread_t *thethd,
./srclib/apr/include/apr_portable.h:APR_DECLARE(apr_status_t) apr_os_thread_pupt(apr_thread_t **thd,
$ grep pupt `find . -name '*.c'`
./server/exports.c:const void *ap_hack_apr_os_exp_time_pupt = (const void *)apr_os_exp_time_pupt;
./server/exports.c:const void *ap_hack_apr_os_thread_pupt = (const void *)apr_os_thread_pupt;
./srclib/apr/threadproc/beos/thread.c:apr_status_t apr_os_thread_pupt(apr_thread_t **thd, apr_os_thread_t *thethd,
./srclib/apr/threadproc/unix/thread.c:apr_status_t apr_os_thread_pupt(apr_thread_t **thd, apr_os_thread_t *thethd,
./srclib/apr/threadproc/win32/thread.c:APR_DECLARE(apr_status_t) apr_os_thread_pupt(apr_thread_t **thd,
./srclib/apr/time/unix/time.c:apr_status_t apr_os_exp_time_pupt(apr_exploded_time_t *aprtime,
./srclib/apr/time/win32/time.c:APR_DECLARE(apr_status_t) apr_os_exp_time_pupt(apr_exploded_time_t *aprtime,
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: apr_ function prefixes
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 8 Feb 2001, Garrett Rooney wrote:
> on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put
> and apr_os_thread_put. i assume that's wrong, since i can't for the
> life of me figure out what pupt would mean ;-)
whoops! you're right, i'll fix that and pupt the changes back in cvs.
Re: apr_ function prefixes
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Feb 07, 2001 at 10:59:47PM -0800, Doug MacEachern wrote:
> On Wed, 7 Feb 2001, B. W. Fitzpatrick wrote:
>
> > +1. Wow that looks great. A toast to consistency!
>
> i'll drink to that :)
>
> > Is there any way you could forward along the conversion script that you
> > used (Or is that the one you sent last week)? This is going to break
> > Subversion a bit, and maybe I (or Greg) can get those changes in and
> > committed first thing in the morning.
>
> sure:
> http://apr.apache.org/~dougm/apr_rename.pl
i'm not entirely sure, since i'm not too familiar with apr, and i don't
have the time to go through and check right now, but your script looks
like it has a few typos.
on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put
and apr_os_thread_put. i assume that's wrong, since i can't for the
life of me figure out what pupt would mean ;-)
-garrett
--
garrett rooney my pid is inigo montoya.
rooneg@electricjellyfish.net you kill -9 my parent process.
http://electricjellyfish.net/ prepare to vi.
Re: apr_ function prefixes
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Feb 08, 2001 at 09:10:48AM -0600, B. W. Fitzpatrick wrote:
> On Thursday, February 8, 2001, at 12:59 AM, Doug MacEachern wrote:
>...
> > sure:
> > http://apr.apache.org/~dougm/apr_rename.pl
> >
> > quick-n-dirty, but seems to work ok.
>
> It looks like Greg has taken care of Subversion, but did anyone else see
> Doug's commit message go by or did my mailer drop it on the floor?
I deleted the thing (it was over 800k). I'm not sure which mail list it was
sent to, but it probably went to the httpd-2.0-cvs mailing list rather than
APR's list.
The other alternative (which I'd doubt) is that your mail system rejected it
due to size.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Feb 08, 2001 at 02:44:08PM -0800, rbb@covalent.net wrote:
> > > On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote:
> > >
> > >> It looks like Greg has taken care of Subversion, but did anyone else see
> > >> Doug's commit message go by or did my mailer drop it on the floor?
> > >
> > > i committed at the top-level and it mailed the diff for everything to
> > > httpd-2.0-cvs@apache.org
> >
> > Urgh. Guess it's time for me to subscribe to a new list.
> >
> > :)
>
> I'm trying to figure out how to make CVS send mail to the right
> repository, even if the commit is from a higher directory.
Tough problem. And you better know your Perl :-)
Do you intend to create multiple messages, or just send the same one to
(all) mailing lists?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote:
> Urgh. Guess it's time for me to subscribe to a new list.
i probably should have done two commits, the apr tree then httpd-2.0
Re: apr_ function prefixes
Posted by rb...@covalent.net.
> > On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote:
> >
> >> It looks like Greg has taken care of Subversion, but did anyone else see
> >> Doug's commit message go by or did my mailer drop it on the floor?
> >
> > i committed at the top-level and it mailed the diff for everything to
> > httpd-2.0-cvs@apache.org
>
> Urgh. Guess it's time for me to subscribe to a new list.
>
> :)
I'm trying to figure out how to make CVS send mail to the right
repository, even if the commit is from a higher directory.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: apr_ function prefixes
Posted by "B. W. Fitzpatrick" <fi...@apple.com>.
On Thursday, February 8, 2001, at 10:36 AM, Doug MacEachern wrote:
> On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote:
>
>> It looks like Greg has taken care of Subversion, but did anyone else see
>> Doug's commit message go by or did my mailer drop it on the floor?
>
> i committed at the top-level and it mailed the diff for everything to
> httpd-2.0-cvs@apache.org
Urgh. Guess it's time for me to subscribe to a new list.
:)
-Fitz
Re: apr_ function prefixes
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote:
> It looks like Greg has taken care of Subversion, but did anyone else see
> Doug's commit message go by or did my mailer drop it on the floor?
i committed at the top-level and it mailed the diff for everything to
httpd-2.0-cvs@apache.org
Re: apr_ function prefixes
Posted by "B. W. Fitzpatrick" <fi...@apple.com>.
On Thursday, February 8, 2001, at 12:59 AM, Doug MacEachern wrote:
> On Wed, 7 Feb 2001, B. W. Fitzpatrick wrote:
>
>> +1. Wow that looks great. A toast to consistency!
>
> i'll drink to that :)
>
>> Is there any way you could forward along the conversion script that you
>> used (Or is that the one you sent last week)? This is going to break
>> Subversion a bit, and maybe I (or Greg) can get those changes in and
>> committed first thing in the morning.
>
> sure:
> http://apr.apache.org/~dougm/apr_rename.pl
>
> quick-n-dirty, but seems to work ok.
It looks like Greg has taken care of Subversion, but did anyone else see
Doug's commit message go by or did my mailer drop it on the floor?
-Fitz
Re: apr_ function prefixes
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 7 Feb 2001, B. W. Fitzpatrick wrote:
> +1. Wow that looks great. A toast to consistency!
i'll drink to that :)
> Is there any way you could forward along the conversion script that you
> used (Or is that the one you sent last week)? This is going to break
> Subversion a bit, and maybe I (or Greg) can get those changes in and
> committed first thing in the morning.
sure:
http://apr.apache.org/~dougm/apr_rename.pl
quick-n-dirty, but seems to work ok.
Re: apr_ function prefixes
Posted by "B. W. Fitzpatrick" <fi...@apple.com>.
On Wed, 7 Feb 2001, Doug MacEachern wrote:
> to see the files that will change and the line number/name change:
> http://perl.apache.org/~dougm/apr_rename.txt
+1. Wow that looks great. A toast to consistency!
Is there any way you could forward along the conversion script that you
used (Or is that the one you sent last week)? This is going to break
Subversion a bit, and maybe I (or Greg) can get those changes in and
committed first thing in the morning.
-Fitz
Re: apr_ function prefixes
Posted by Doug MacEachern <do...@covalent.net>.
to see the files that will change and the line number/name change:
http://perl.apache.org/~dougm/apr_rename.txt
feel free to shout if anything looks wrong, i won't commit for a few
hours.
Re: apr_ function prefixes
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 6 Feb 2001, Roy T. Fielding wrote:
> +1 a.s.a.p.
ok, i'm planning todo it later this evening.
Re: apr_ function prefixes
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
+1 a.s.a.p.
....Roy
Re: apr_ function prefixes
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 07, 2001 at 06:50:09AM -0500, Kevin Pilch-Bisson wrote:
> On Tue, Feb 06, 2001 at 03:05:30PM -0800, Greg Stein wrote:
> > On Tue, Feb 06, 2001 at 09:38:16AM -0500, Kevin Pilch-Bisson wrote:
> > >...
> > > +1 for this, but only if it is done soon. As Ryan said recently, APR is
> > > approaching the Beta stage, so API's shouldn't change much. However, I
> > > think this is a useful change.
> >
> > A little process comment here: Ryan is a single voice out of all of us here.
> > I want to see a "beta" also, but just because Ryan or I say so doesn't make
> > it true.
> >
> > Basically, we release it as a beta when we (the group) think it is a beta.
> >
> My apologies if I stepped on any toes. I didn't mean to say that Ryan
> had the final say or anything like that. I was just referring to the
> fact that Ryan recently suggested not changing API's much, because APR
> was approaching Beta. All I meant to say was that I thought this change
> was important, even though it _DOES_ in fact change those API's, but
> that it should be done soon if it is done, because the API should be
> stable once APR is `Beta'd.
>
> If you interpreted it differently, please rest assured that this was all
> I meant to imply.
Hehe... have no fear of my toes. Around mailing lists, I wear asbestos
pajamas and steel-toed boots. :-)
It is only what I said: a "comment". You did say you were lurking for a
while and relatively new, so I simply filled in a bit of info on how the
process works. No big whoop.
I think we'll be changing APIs until we release. After that, then it will be
trickier.
Trying to freeze APIs at any point before a release just means that you
release with sucky APIs. Fix them first, then release. After you release,
you have to deal with the crap you built, but that is a different story for
a different time :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Tue, Feb 06, 2001 at 03:05:30PM -0800, Greg Stein wrote:
> On Tue, Feb 06, 2001 at 09:38:16AM -0500, Kevin Pilch-Bisson wrote:
> >...
> > +1 for this, but only if it is done soon. As Ryan said recently, APR is
> > approaching the Beta stage, so API's shouldn't change much. However, I
> > think this is a useful change.
>
> A little process comment here: Ryan is a single voice out of all of us here.
> I want to see a "beta" also, but just because Ryan or I say so doesn't make
> it true.
>
> Basically, we release it as a beta when we (the group) think it is a beta.
>
My apologies if I stepped on any toes. I didn't mean to say that Ryan
had the final say or anything like that. I was just referring to the
fact that Ryan recently suggested not changing API's much, because APR
was approaching Beta. All I meant to say was that I thought this change
was important, even though it _DOES_ in fact change those API's, but
that it should be done soon if it is done, because the API should be
stable once APR is `Beta'd.
If you interpreted it differently, please rest assured that this was all
I meant to imply.
--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
PGP Public Key At http://pgp.pilch-bisson.net
Re: apr_ function prefixes
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 06, 2001 at 09:38:16AM -0500, Kevin Pilch-Bisson wrote:
>...
> +1 for this, but only if it is done soon. As Ryan said recently, APR is
> approaching the Beta stage, so API's shouldn't change much. However, I
> think this is a useful change.
A little process comment here: Ryan is a single voice out of all of us here.
I want to see a "beta" also, but just because Ryan or I say so doesn't make
it true.
Basically, we release it as a beta when we (the group) think it is a beta.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
Posted by rb...@covalent.net.
> > there's a number of places where apr (and httpd) is not consistent with
> > prefixes or doesn't use one at all (beyond apr_ or ap_).
> > personally, i like to see functions named with the prefix of the base type
> > (struct) they operate on if possible. for example, apr_xlate_t related
> > functions all have an apr_xlate_ prefix, this is goodness. for certain
> > types, many, but not all related functions use a consistent prefix
> > (e.g. apr_table_t), for some there is no prefix at all.
> > i know this might be considered "late in the game", but in reality apr is
> > very young software. consistent/meaningful naming should start now,
> > rather than 2 years down the road when i suspect it'll be in pretty
> > widespread use. below are some suggestions, i think i still have a
> > rename script handy if there's consensus to move forward on some or all.
> >
> <snip renaming>
>
> Although I haven't been much of a contributor to APR, I have been
> working with the Subversion group a little bit, so I lurk around here,
> since this stuff affects subversion too. I would have to say that I am
> +1 for this, but only if it is done soon. As Ryan said recently, APR is
> approaching the Beta stage, so API's shouldn't change much. However, I
> think this is a useful change.
I hate to be left out of giving a +1, so...... -1.... oh wait, I meant
+1. :-) :-)
Please doug, do this soon. The only thing I would ask is exactly what
Will said, just put this stuff in the compat header file too.
Thanks a lot,
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: apr_ function prefixes
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Mon, Feb 05, 2001 at 09:21:55PM -0800, Doug MacEachern wrote:
> there's a number of places where apr (and httpd) is not consistent with
> prefixes or doesn't use one at all (beyond apr_ or ap_).
> personally, i like to see functions named with the prefix of the base type
> (struct) they operate on if possible. for example, apr_xlate_t related
> functions all have an apr_xlate_ prefix, this is goodness. for certain
> types, many, but not all related functions use a consistent prefix
> (e.g. apr_table_t), for some there is no prefix at all.
> i know this might be considered "late in the game", but in reality apr is
> very young software. consistent/meaningful naming should start now,
> rather than 2 years down the road when i suspect it'll be in pretty
> widespread use. below are some suggestions, i think i still have a
> rename script handy if there's consensus to move forward on some or all.
>
<snip renaming>
Although I haven't been much of a contributor to APR, I have been
working with the Subversion group a little bit, so I lurk around here,
since this stuff affects subversion too. I would have to say that I am
+1 for this, but only if it is done soon. As Ryan said recently, APR is
approaching the Beta stage, so API's shouldn't change much. However, I
think this is a useful change.
--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
PGP Public Key At http://pgp.pilch-bisson.net
Re: apr_ function prefixes
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
+1 ... we need these changes, only we have attacked this as time has permitted.
My only comment, take this group:
> apr_get_shm_name apr_shm_name_get
> apr_set_shm_name apr_shm_name_set
> apr_open_shmem apr_shm_open
I'd personally like to see apr_shm_get/set_name (and agree with you on apr_shm_open)
but I'd much prefer the apr_shm prefix on all shm fn's, etc.
Renaming today is fine [although I haven't finished the jobs I signed up for, yet]
since we have apr_compat.h (or apu_compat.h for apr-util symbols), and that should
help avoid breaking existing consumers, or get them working again quickly.
APR has just sort of grown, and since we have a bunch of folks moving stuff into
apr, we have done is several different ways. Any patches to clean this up would
be quite appropriate.
Bill
----- Original Message -----
From: "Doug MacEachern" <do...@covalent.net>
To: <de...@apr.apache.org>
Sent: Monday, February 05, 2001 9:21 PM
Subject: apr_ function prefixes
> there's a number of places where apr (and httpd) is not consistent with
> prefixes or doesn't use one at all (beyond apr_ or ap_).
> personally, i like to see functions named with the prefix of the base type
> (struct) they operate on if possible. for example, apr_xlate_t related
> functions all have an apr_xlate_ prefix, this is goodness. for certain
> types, many, but not all related functions use a consistent prefix
> (e.g. apr_table_t), for some there is no prefix at all.
> i know this might be considered "late in the game", but in reality apr is
> very young software. consistent/meaningful naming should start now,
> rather than 2 years down the road when i suspect it'll be in pretty
> widespread use. below are some suggestions, i think i still have a
> rename script handy if there's consensus to move forward on some or all.
>
> apr_pollfd_t:
> apr_add_poll_socket apr_poll_socket_add
> apr_clear_poll_sockets apr_poll_socket_clear
> apr_get_polldata apr_poll_data_get
> apr_get_revents apr_poll_revents_get
> apr_mask_poll_socket apr_poll_socket_mask
> apr_remove_poll_socket apr_poll_socket_remove
> apr_set_polldata apr_poll_data_set
> apr_setup_poll apr_poll_setup
>
> apr_time_t:
> apr_now apr_time_now
>
> apr_array_header_t:
> apr_append_arrays apr_array_append
> apr_copy_array apr_array_copy
> apr_copy_array_hdr apr_array_copy_hdr
> apr_make_array apr_array_make
> apr_push_array apr_array_push
>
> apr_socket_t:
> apr_close_socket apr_socket_close
> apr_create_socket apr_socket_create
> apr_get_sockaddr apr_socket_addr_get
> apr_get_socketdata apr_socket_data_get
> apr_set_socketdata apr_socket_data_set
>
> apr_sockaddr_t:
> apr_getaddrinfo apr_sockaddr_info_get
> apr_get_ipaddr apr_sockaddr_ip_get
> apr_set_ipaddr apr_sockaddr_ip_set
> apr_set_port apr_sockaddr_port_set
> apr_get_port apr_sockaddr_port_get
>
> apr_pool_t:
> apr_create_pool apr_pool_create
> apr_destroy_pool apr_pool_destroy
> apr_get_userdata apr_pool_userdata_get
> apr_set_userdata apr_pool_userdata_set
> apr_kill_cleanup apr_pool_cleanup_kill
> apr_run_cleanup apr_pool_cleanup_run
> apr_null_cleanup apr_cleanup_null
> apr_register_cleanup apr_cleanup_register
> apr_make_sub_pool apr_pool_sub_make
> apr_note_subprocess apr_pool_note_subprocess
>
> apr_lock_t:
> apr_child_init_lock apr_lock_child_init
> apr_create_lock apr_lock_create
> apr_destroy_lock apr_lock_destroy
> apr_get_lockdata apr_lock_data_get
> apr_set_lockdata apr_lock_data_set
> apr_lock apr_lock_aquire
> apr_unlock apr_lock_release
>
> apr_table_:
> apr_clear_table apr_table_clear
> apr_copy_table apr_table_copy
> apr_make_table apr_table_make
> apr_overlap_tables apr_table_overlap
> apr_overlay_tables apr_table_overlay
>
> apr_file_t:
> apr_open apr_file_open
> apr_close apr_file_close
> apr_create_namedpipe apr_file_namedpipe_create
> apr_create_pipe apr_file_pipe_create
> apr_dupfile apr_file_dup
> apr_flush apr_file_flush
> apr_eof apr_file_eof
> apr_ferror apr_file_error
> apr_fgets apr_file_gets
> apr_fprintf apr_file_printf
> apr_full_read apr_file_read_file
> apr_full_write apr_file_write_full
> apr_getc apr_file_getc
> apr_ungetc apr_file_ungetc
> apr_putc apr_file_putc
> apr_puts apr_file_puts
> apr_read apr_file_read
> apr_write apr_file_write
> apr_writev apr_file_writev
> apr_seek apr_file_seek
> apr_get_filedata apr_file_data_get
> apr_getfileinfo apr_file_info_get
> apr_get_filename apr_file_name_get
> apr_get_file_pool apr_file_pool_get
> apr_get_pipe_timeout apr_file_pipe_timeout_get
> apr_set_pipe_timeout apr_file_pipe_timeout_set
> apr_lock_file apr_file_lock
> apr_unlock_file apr_file_unlock
> apr_open_stderr apr_file_open_stderr
> apr_open_stdout apr_file_open_stderr
> apr_remove_file apr_file_remove
> apr_rename_file apr_file_rename
> apr_set_filedata apr_file_data_set
> apr_setfileperms apr_file_perms_set
>
> apr_procattr_t:
> apr_createprocattr_init apr_procattr_create
> apr_setprocattr_childerr apr_procattr_child_err_set
> apr_setprocattr_childin apr_procattr_child_in_set
> apr_setprocattr_childout apr_procattr_child_out_set
> apr_setprocattr_cmdtype apr_procattr_cmdtype_set
> apr_setprocattr_detach apr_procattr_detach_set
> apr_setprocattr_dir apr_procattr_dir_set
> apr_setprocattr_io apr_procattr_io_set
> apr_setprocattr_limit apr_procattr_limit_set
>
> apr_proc_t:
> apr_create_process apr_proc_create
> apr_fork apr_proc_fork
> apr_kill apr_proc_kill
> apr_probe_writable_fds apr_proc_probe_writable_fds
> apr_reap_other_child apr_proc_other_child_read
> apr_register_other_child apr_proc_other_child_register
> apr_unregister_other_child apr_proc_other_child_unregister
> apr_check_other_child apr_proc_other_child_check
> apr_wait_all_procs apr_proc_wait_all_procs
> apr_wait_proc apr_proc_wait
> apr_detach apr_proc_detach
>
> apr_thread_t:
> apr_create_thread apr_thread_create
> apr_get_threaddata apr_thread_data_get
> apr_set_threaddata apr_thread_data_set
> apr_thread_detach apr_thread_detach
>
> apr_threadkey_t:
> apr_get_threadkeydata apr_threadkey_data_get
> apr_set_threadkeydata apr_threadkey_data_set
> apr_create_thread_private apr_threadkey_private_create
> apr_delete_thread_private apr_threadkey_private_delete
> apr_get_thread_private apr_threadkey_private_get
> apr_set_thread_private apr_threadkey_private_set
>
> apr_threadatt_t:
> apr_create_threadattr apr_threadattr_create
> apr_getthreadattr_detach apr_threadattr_detach_set
> apr_setthreadattr_detach apr_threadattr_detach_get
>
> apr_dir_t:
> apr_make_dir apr_dir_make
> apr_remove_dir apr_dir_remove
>
> apr_uuid_t:
> apr_format_uuid apr_uuid_format
> apr_get_uuid apr_uuid_parse
> apr_parse_uuid apr_uuid_parse
>
> apr_shmem_t:
> apr_get_shm_name apr_shm_name_get
> apr_set_shm_name apr_shm_name_set
> apr_open_shmem apr_shm_open
>
> apr_hash_t:
> apr_make_hash apr_hash_make
>
> misc:
> apr_getpass apr_password_get
> apr_validate_password apr_password_validate
> apr_generic_hook_get apr_hook_generic_get
> apr_hook_generic apr_hook_generic_add
>
>