httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: vetoing hide.h
Date Wed, 01 Apr 1998 02:25:48 GMT
On Tue, 31 Mar 1998, Roy T. Fielding wrote:

> >Erm... the whole point of hide.h from the beginning is that it is a short
> >term solution.  We already know the long term solution: 2.0.  
> >
> >So do you want a short long term solution or a long short term solution?
> >We already have a short term one and a long term one.
> I want a long-term solution or a short-term solution that is not worse
> than the problem being solved.

I'm afraid I'm not convinced that hide.h is that horrible.  Your saying
you thought about it is fine, but it isn't a reason.  Regardless, vetos
still need a reason.  You never could and still can't veto something "just
because I don't like it".

The reasons you gave:

   1) it is poor software engineering (makes the code harder to read
      for the sake of saving the one-time task of replacing the current
      code with new symbol names).

How is the code harder to read?  I don't follow.  The code
doesn't change so how can it suddenly become harder to read?

Debugging takes a bit more effort, but hey: if you are upset about that
set HIDE=no.  After all, the current build config doesn't make anything I
can usefully debug.  Should we include '-g' by default? 

   2) it is a maintenance nightmare because it becomes too easy to
      arbitrarily choose which symbol to use.

I'm afraid I have no idea what you are talking about.

   3) it is a 3rd-party nightmare because it breaks the binary API
      in a way that is nearly impossible to see unless you happen to
      be on this mailing list.

Huh?  How does it break the binary API?  If your settings don't match,
sure, but if we default to HIDE=yes that isn't a big deal and the binary
API is already broken horribly.  

Mass renaming of names in 1.3 causes a whole load of work and breaks the
binary _and_ source API, requiring silly hacks to try to get around it and
still requiring more module source changes. 

There is no point in trying to change all non-static function names for
1.3.  It is counterproductive.  Leave it for 2.0 and leave 1.3 as it is
right now.

View raw message