httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@worldgate.com>
Subject Re: vetoing hide.h
Date Tue, 31 Mar 1998 05:58:25 GMT
I really do not think we are in a position right now where we should be
changing the public API to use new names to fix this issue.  The pain it
would cause isn't worth it because it isn't fixing the API.

Let it be, and do 2.0 right from the start.  This is not something that
impacts the vast majority of users (or developers for that matter).  All
this does is waste time bickering that is better spent on other things.  I
know bickering is an art that we all (especially me) know and love, but
this is unsolvable in 1.3 IMHO.

The 1.3 API has broken parts.  Accept it.  I do not support major changes
in naming in 1.3.x.  I don't like hide.h, but I support it because it is a
quick way to avoid having to mess with peoples heads, and it fixes the
namespace collision problems. 

I question if HIDE=yes is the right default though.  There are only a
small number of people that need this or would benefit from it at all.
There is very very little benefit to people unless they _need_ this to
make it compile (ie. avoid conflicts), so defaulting to HIDE=yes doesn't
make sense to me.  I don't by the consistency argument, since it trades
off consistency with however many years of history for consistency with
the few people that need it.

Those people that do need it, need it badly and will fall over and pray
at your feet if you give them the ability to make it work by editing a
"no" to "yes".

 Changing the actual names is a big deal, because it isn't just changing
names of API functions, but it requires changing names of internal
cross-file (ie. non-static) functions as well. 



Mime
View raw message