httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: 2.0 naming
Date Wed, 26 Apr 2000 21:41:17 GMT
> From: Doug MacEachern [mailto:dougm@covalent.net]
> Sent: Wednesday, April 26, 2000 3:52 PM
> 
> > The following names are problematic...
> >  
> > > 1. API_EXPORT
> > > 1. API_EXPORT_NONSTD
> > > 1. MODULE_VAR_EXPORT
> > > 1. API_VAR_EXPORT
> > > 1. CORE_EXPORT
> > > 1. CORE_EXPORT_NONSTD
> > 
> > API_* will become one of TWO different sets of names, and I was
> > going to kep API_* for the Apache core componenents.  CORE_*
> > wrappers are actually notes to the implementor, not really any
> > different from API_ wrappers.  *_VAR_EXPORT really should
> > become *_EXPORT_VAR, and MODULE_VAR_EXPORT become simply EXPORT_VAR,
> > since it is involitale (it won't change by context.)
> > 
> > All API_* declarations in the apr library headers were to become 
> > APR_*.  I don't care if these become AP_ instead, however. The
> > point is they must be split, and declarations for APR_ (or AP_)
> > updated in the apr header files.
> 
> you sorta lost me, can i leave those names for you to tackle?

Assuredly.
 
> personally, i'd like to see the AP_ prefix used in apr as 
> well, as all the
> functions are prefixed ap_ and not apr_.  but, i probably missed that
> discussion already.

Well... so are the httpd functions, but that doesn't keep us from 
requiring two or more pools of function wrappers (one per shared library
target, except in the case of MODULE_ stuff which is always simply
exported and never imported - I hope).

I will take that as a + for AP_EXPORT* to wrap apr labels, and tackle 
those alone over the weekend.  I will leave (correct, in some cases) 
API_EXPORT* for the apache kernel.  If anyone doesn't like that when 
I finish... well, then they will be able to grep the whole nonsense
to more meaningful wrapper names.


Mime
View raw message