httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@hyperreal.org>
Subject prefixes
Date Mon, 30 Mar 1998 01:41:27 GMT
At 05:53 PM 3/29/98 -0800, Dean Gaudet wrote:
>apapi_vformatter contains no dependencies on the core. 

Moving it to ap_vformatter was the right thing to do, then.

>I don't see the point in having 5 million different prefixes.  I don't see
>the point in having 5 different prefixes.  I would rather have one prefix
>and use it everywhere.  At the moment we've got the following:
>
>AP_	stuff that doesn't have any other prefix
>ap_	some stuff that fits your description of generic library tools
>	with no dependency on core (i.e. ap_snprintf), and some stuff
>	that does depend on core (i.e. ap_escape_quotes)

That should be cleaned up.  What other funcs besides ap_escape_quotes?
Looks like that's the only func in src/ap that takes a pool pointer as a
parameter, and could probably be modified to handle static buffers...

>apapi_  two random new core functions
>aplog_  another random core function

Looks like consensus is to use apapi_ for API functions.

>os_     some other random core functions

Wasn't this for routines that turn OS-nonspecific semantics into
OS-specific calls?  My vote would be to make this ap_.

>... and at least one more that's proposed but unused, appri_ or whatever
>you want to call it.

I think the AP_ system makes this unnecessary anymore, true?

>This is ridiculous.  Apache is 72k lines of code.  If we can't keep our
>own symbols from colliding with each other then we've got serious problems.
>We need only one prefix.

In so far as we want to have a 1) library of reusable code and 2) real API,
having distinct prefixes is helpful.

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Optimism is a strategy for making                         brian@apache.org
a better future." - Noam Chomsky                        brian@hyperreal.org

Mime
View raw message