apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: renaming apr_filetype enum entries
Date Tue, 21 Sep 2004 03:44:10 GMT
Greg Stein wrote:
> On Sun, Sep 19, 2004 at 06:01:01PM -0400, Stas Bekman wrote:
>>Greg Stein wrote:
>>>IMO, projects should just use the API of the oldest major revision that
>>>they can, and forget a bunch of compat stuff. If a project codes against
>>>version 1.0, then it will work for everything after that.
>>mod_perl 2.0 needs to support apr 0.9.x (as long as 2.0.x requires it) and 
>>it'll probably support 2.2 as well. So if those defines are added in apr 
>>1.1 we can't use them w/o the compat layer, to support older libapr.
> That's what I'm saying: don't use them. Make your life easier and forget
> the compat layer. For some people, they'll go ahead and code to the new
> 1.1 API, and they'll use the better symbol names.
> But, your call. :-)

I've lost you Greg. Do you suggest not to use the new longer names? If so, 
why do you think I'm trying to change them? If we expose the short names 
then what's the point of all this mini-project?

>>>It will transparently work with both if we use APR_REG and friends. I
>>>don't want to add a bunch of #ifdef code to httpd if it isn't needed.
>>Right, but there were just few opinions so far of whether both should be 
>>supported or not. I just thought that the decision wasn't cast in stone yet.
> Both *WILL* be supported. There is no question to that. That's an absolute
> baesd on the compat rules. The only way to avoid supporting both is to
> shoot for a 2.0 release, and I'll veto any change that forces a 2.0 so
> darned soon. I would expect to live in 1.x land for at least a couple
> years. When our API gets too kludgy because of deprecation or whatever,
> *then* we move to 2.0 and clear that out.


> I believe the only question on the table is whether the short form macros
> (e.g. APR_REG) are part of the API, or whether they are deprecated.
> But they *will* still exist.


>>>Well, what you're really doing is providing a 1.1 API to all users. I
>>>understand the motivation, but I'm not personally interested in that for
>>You mean, you'd like to keep the old short defines used across httpd? and 
>>inside libapr?
> Just in httpd. APR can use the new macros, of course.

OK, so now I'm asking whether the short macros should be deprecated (i.e. 
whether the introduction of the new longer macros should be followed by a 
replacement of the short ones across httpd and/or apr.

I understand that you are:

-1: replace in httpd
+0: replace in apr


what others think? so we can proceed with the change... thanks.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

View raw message