httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: cvs commit: apache-1.3 STATUS
Date Tue, 07 Apr 1998 22:06:46 GMT
Jim Jagielski wrote:
> 
> Rodent of Unusual Size wrote:
> >
> > Paul Sutton wrote:
> > >
> > > Anyway, moving forward, the problem now with this situation is that the
> > > two veots (HIDE and ap_) effectively create a stalemate situation. The
> > > former means we have to rename symbols. So everyone votes for their
> > > favourites and ap_* wins. But the second veto prevents that vote from
> > > being implemented. What now?
> >
> > I will readily and cheerfully rescind my veto if Roy will remove
> > his time-limit and let the group hash its way to a generally-accepted
> > solution.  I'd like him to reconsider his veto, or at least take
> > another stab at justifying it, since it appears to be inadequately
> > supported to the taste of several people.
> >
> 
> Either we have a hack (ala HIDE) or we do it right. But replacing a
> hack with a hack (which the general ap_ prefix is, IMO) doesn't
> make sense.

Much as I sympathise with the view that global ap_ is a mistake, if I've
understood clearly, there's a simple reason why it does make sense,
which is that HIDE breaks tools, and a general prefix explicitly used in
the code doesn't.

What I object to is reusing something (ap_) that already has semantics
in a way that destroys those semantics. So, if we really must go for a
simple namespace solution let it at least not _subtract_ from what
little classification we already have.

In an ideal world, I can see that we'd like to sort out the whole prefix
question, assigning "correct" prefixes to each function. Sorting out the
namespace issue can be seen as independent. If we can all agree that, I
think it clarifies the situation:

1. We need to do something about overloaded function names.
2. Using a header to redefine them is attractive, but breaks things.
3. Therefore they need to be renamed in place.

Now, if anyone disagrees with my reasoning up to this point, please
explain where I went wrong.

Assuming 1-3 are agreed, we move on:

4. Predicting _what_ may need renaming is difficult, so
5. We should rename all exported functions.

Is everyone still on board? If so, then:

6. We must, therefore, choose a renaming scheme.

I think it is at this point that we part company (i.e. we all agree 6,
but have multiple views about 7). I'd like everyone, even if they don't
agree from here on in, to state clearly whether they agree up to this
point, and if not, why not. It seems to me that in the heat of the
argument, people are losing site of the basis.

Now, I think it is perfectly reasonable to say that the renaming scheme
should not bugger up existing naming conventions (which, IMO, rules out
ap_ as a prefix for this purpose), unless, as a completely separate
issue, we agree that those naming conventions are worthless.

Also, the issue of whether we should use this opportunity to name things
more sensibly is, it seems to me, an independent issue.

Hmmm ... looks like I've argued myself out of the stance I'd've liked to
have taken. Oh well. Seems to me we are left with two things:

A. The indisputable fact we need to rename stuff, but we need to choose
a scheme for doing so (which boils down to "choose a prefix").

B. A desire to rename things in a more sensible way.

Seems to me that agreeing on A does not preclude doing B. So can we get
A out of the way, and debate B independently (and after we've resolved
A)?

Or have I lost it completely? Or should I just shut my big mouth?

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|  Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd,     |Apache-SSL author    http://www.apache-ssl.org/
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Mime
View raw message