httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: ap_ vs apr_
Date Wed, 02 Aug 2000 07:57:52 GMT
>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_

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.


View raw message