Date: Mon, 13 Apr 1998 18:21:27 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: gen_test_char and gen_uri_delims
In-Reply-To: <199804140035.UAA24741@devsys.jaguNET.com>
Message-ID: <Pine.LNX.3.96dg4.980413181715.15402C-100000@twinlark.arctic.org>
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 Mon, 13 Apr 1998, Jim Jagielski wrote:

> Dean Gaudet wrote:
> > 
> > We do have directory names for a reason.  src/include includes .h files
> > which export interfaces between parts of the server.
> 
> Except for a very very few exceptions (like mod_rewrite.h in modules/standard)
> ALL header files are in ./include. One very good reason is to have
> some logical use of -I when compiling. At no point is "export" any
> reason at all... It's to have one logical place for include files.

"very very few exceptions"  gee, that's the basis of a solid argument.

If you don't believe that .h files export interfaces then I'm sorry, but
maybe you should go read some "how to program in C" books.  Have you
noticed that every single system .h file exports an interface?  Maybe
there's a reason for that. 

> > src/helpers are part
> > of the Configure portability/configuration mgmt tool. 
> > 
> > On the other hand, main/gen_util_uri is a piece of the code required to
> > build util_uri.o.  It's needed by nothing else, in fact nothing else
> > should even know it exists.  If all the world was ASCII it wouldn't even
> > need to be there -- it could be done once and ignored until protocol or
> > algorithm changes meant it would need updating.
> > 
> > It's somewhat like putting all of the proxy in modules/proxy. 
> 
> Except the analogy doesn't quite hold.

Hah.  So then you believe that the rest of the server needs to know about
the inner workings of mod_proxy?  Somehow modules/proxy/mod_proxy.h
doesn't have to be in the include directory, and neither should it be.  It
doesn't export anything the rest of the server needs to know.

As soon as you move something out of a subdirectory you widen its scope of
influence.  You beg people to code to the interface you are suddenly
exporting.  If test_char.h were in include I bet it wouldn't take long for
someone to use it for their own hand-coded stuff... stuff which should go
into main.  Such as the ap_is_token() I just suggested to the fellow with
the mod_usertrack patch.

If you export test_char.h then you beg people to lock us into that
interface.  Which is just plain stupid.  That is an *implementation
detail*.  Any modern software engineering book you read will explain that
implementation details should not be part of abstract interfaces. 

> > Suppose we had a foo.y in main, and it was only used in an abstract way by
> > another routine in main.  Would you suggest then that bison be placed in
> > helpers/ and foo.tab.h be placed in include?  I wouldn't, it breaks the
> > abstraction.  gen_foo aren't exported interfaces, it's the functions which
> > are built out of them which are abstracted and exported.
> > 
> 
> It looks plain ugly to have header files and 2 binaries in ./src/main,
> especially when it's not that way anyplace else.

Then call them .c instead of .h.  Happy now?  Is the difference any more
obvious to you?

I called them .h because I figured people would complain if I called them
anything else; and I figure there's a compiler out there that won't like
it if they're called anything else. 

> But I have no intention of debating this at all... it's obvious.

It's obvious that you, like me, refuse to give up the last word. 

Dean