You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU> on 2000/08/02 09:57:52 UTC
Re: ap_ vs apr_
>yeah, i don't think we should ever have both ap_blah and apr_blah in the
>source tree. it'll just be up to us humans to make sure that doesn't
>happen, rather than the linker :)
>
>i think most everybody would agree, if we were starting from scratch and
>there was no 1.3.x., using a different prefix for libapr functions would
>be the right thing to do. i don't expect this change to be much more
>painful than the big namespace cleanup when every extern was given an ap_
>prefix.
Well, while you are at it you might as well also change all of the
functions calls to move the pool back to being the first parameter.
At least then we were consistent. *sigh*
I had two reason for opposing apr_*.
1) It made the code harder to read. Try it on a file with many
calls and see what difference that extra character makes.
2) It meant we had to change the source code whenever someone felt
an existing function should be in APR instead of httpd. Gee, how
many times has that happened in the past few months?
I think it is silly to use the apr_ prefix for anything. I don't even
support the header filenames being called apr_blah instead of ap_blah.
If someone wants to include APR in Apache 1.3, then they can bloody well
cut and paste the routines they need and change the names -- linking
it all into one executable server is just plain loony.
That's my opinion -- I don't care to place a vote. I think that anyone
who changes the names back should be forced to code a new module with
that naming scheme in place before they can commit the change. Realizing
the futility of having to remember where the code was located just to
be able to make a function call was what killed apr_ last time.
....Roy