httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bh...@gensym.com (Ben Hyde)
Subject Re: hide.h
Date Wed, 01 Apr 1998 14:59:05 GMT
The quotes below are from assorted mail.

Paul Sutton wrote:
> Hey this has really livened up this list! 

:-)

Generally Marc Slemko has made most of the points I would
have made, and more concisely than I ever would!  Meanwhile
Roy's replies have kinda sorta convinced me.

Roy writes
> BTW, I will rescind my veto if ...

April fools?  :-) I'm surprised - confused?

Roy wrote:
> It isn't just debugging.  Source code analysis tools, program visualization,
> hypertext programming environments, and even ctags all get confused when
> macros are used to replace function names.  Saying "gee, those tools are
> broken" doesn't help.  Macros like that should only be used for backwards
> compatibility, and even then the decls for those functions must have the
> new name (replacing both def and use in one go is what causes these tools
> to puke).

Clearly what is distasteful about the hide.h solution is the
way it encourages this breakdown in the ecology of tools.  As
soon as you use hide.h to work around the stupid linker then
you don't play well with all the other animals at the C
namespace party.

"The C linker is the universal solvent of programing."

Roy writes
> ... I happen to believe that all of
> our external symbols define the API, whether we like it or not,
> and the right way to segregate functionality is to either make it
> static or place it in an exclusive library.

Absolutely!  

Worse! add in the reachable data structures.

Admit that?  I doubt we all do. It makes it a lot
less shocking that everything in hide.h is suddenly in a file
called *half*api*.h.

This let's us size the API doc problem (which really ought to
be addressed before the redesign problem).  So, hide.h has
400 functions in it, double that to cover the data
structures, write 5 careful lines for each name 400*2*5 and
4,000 lines later and you've got a first draft for the API
design.  No wonder it's TBD.

I don't know if taking hide.h and renaming it to
"api_something" moves us closer to an API design, or just
exacerbates the problem.  At this moment I think it makes
things a little better.

Roy writes:
> ... except that the only thing I want "meaningful" in the prefix 
> is the symbol-collision-avoidance.

That's all I want too.  I don't want to pile on a lot of
other noble goals on this poor prefix.

Can we agree that this a rewrite is basicly neutral on the
API design/doc problem?  Can we open this pandora's box
without falling into the blackhole around the API design
problem?

Ralf writes:
> ... I never the less volunteer to make the
> UpdateSource script out of UpdateHide. ...

The man is a saint.

I guess this is a similar to Torvalds' line about how with
enough eyes every bug is simple.  With enough hands every
project is fun.

I currently lean toward either:
 1. Do the global rewrite.
 2. Proceed on the path we are on.
only slightly in that order.

If we are to do the global rewrite...

many write:
> ... AP_palloc ...
Ken Coar writes
> ... had my carpal-tunnel release surgery already - I don't
> mind the extra typing.  I'm just being generous to the people
> who object to it.  (Whole lot of <g>s there, folx..)

I don't find this funny, my hands hurt to much.  Please
ap_palloc, or less.

If we avoid the tarpit around API rework then the problem
of backward compatibly remains.  The details in getting
this to work out look tedious, but I trust we can shake
them out.

Now that I'm convinced that a global rewrite is a 
generic good.  I'm still having trouble being convinced
it is timely compaired to the ecological damage it is
preempting.   sigh...

   - ben hyde



Mime
View raw message