Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 20129 invoked by uid 6000); 1 Apr 1998 02:25:51 -0000 Received: (qmail 20121 invoked from network); 1 Apr 1998 02:25:50 -0000 Received: from valis.worldgate.com (marcs@198.161.84.2) by taz.hyperreal.org with SMTP; 1 Apr 1998 02:25:50 -0000 Received: from localhost (marcs@localhost) by valis.worldgate.com (8.8.7/8.8.7) with SMTP id TAA29447 for ; Tue, 31 Mar 1998 19:25:48 -0700 (MST) Date: Tue, 31 Mar 1998 19:25:48 -0700 (MST) From: Marc Slemko To: new-httpd@apache.org Subject: Re: vetoing hide.h In-Reply-To: <9803311440.aa13926@paris.ics.uci.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org 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.