httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <ab...@dial.pipex.com>
Subject Re: cvs commit: apache-2.0/src/lib/apr/time/beos access.c
Date Mon, 13 Sep 1999 19:05:56 GMT
I'm flattered with all the attention my patch caused...

I have read and agree with a lot of the comments made, and disagree with
others.  Much of the code is similar to Unix, much is different.  Over time
more code will diverge as more of the native BeOS structures and code are
added and then optimised.  I don't plan on doing all the work myself :-)

I've not had as much time to make a start at this code as I'd hoped (work
and personal life got in the way).  I hope that now we have code I can get
some support from the BeOS community and having actual working code is
always better than just having an idea.  Now we have an APR implementation
that works and can be massaged and optimised for the platform.  I'd rather
do that on platform "clean" code before considering moving it into the Unix
subdirectory.

At a later date if the code is still totally similar then I'll do the work
and merge the two together.  :-)) (Did I just say that???)

Personally I hate code with too many #ifdef's so I liked Ryan's approach.

I hope that this answers some peoples thoughts???

david
----- Original Message -----
From: Ben Hyde <bhyde@pobox.com>
To: <new-httpd@apache.org>
Sent: 13 September 1999 14:06
Subject: Re: cvs commit: apache-2.0/src/lib/apr/time/beos access.c


> Ryan Bloom <rbb@raleigh.ibm.com> writes:
> ...
> > I will at this point leave it up to the maintainer of each platform to
> > determine if they want to merge their code into the unix directory.  If
> > everybody who is working on APR merges their code in, we will remove the
> > subdirectory structure that currently exists.
>
> Fair, but unlikely to actually give rise to any change.  It maybe too
> late for for BEOS and Windows.
>
> > > I prefer
> > >
> > > return_type f(arg_type a1, arg_type a2)
> > > {
> > > #ifdef VARIATIONA
> > > ...
> > > #endif
> > > #ifdef VARIATIONB
> > > ...
> > > #endif
> > > }
> >
> > As it happens, I hate this style with a passion.  I this it makes the
code
> > harder to read.  On similar platforms, I would much rather have:
> >
> > #ifdef VARIATIONA
> > return_type f(arg_type a1, arg_type a2)
> > {
> > ...
> > }
> > #elif VARIATIONB
> > return_type f(arg_type a1, arg_type a2)
> > {
> > ...
> > }
>
> #elif is fine.
>
> Doing the #if.. at toplevel licenses files like 1.3's http_main.c.
> Code that didn't absolutely have to fork does, then it starts to
> change so one branch has enhanements, variations of sequencing,
> bug fixes while the other doesn't. For example in http_main
> today you find these line in one part.
> ---
> static void child_main(int child_num_arg)
> {
>     ...
>     ap_block_alarms();
>     ...
>     pchild = ap_make_sub_pool(pconf);
> --- and these lines in another ---
> void worker_main(void)
> {
>   ...
>     pchild = ap_make_sub_pool(pconf);
> ---
> The reader is left unsure if those variations are by design
> or chance.  This kind of dry rot is encouraged by forked a bundle
> of code on day one - because that was easiest - and then pushing
> the two branches up hill ever since.
>
> > Provided the difference was big enough to replace the whole function. I
> > think this makes it much easier to modify the function, and you are less
> > likely to end up with this case (I have seen code like this in multiple
> > projects, and it is impossible to maintain unless you are the original
> > author.)
>
> At the heart of my preference for the style I suggest is that is
> creates a huge improvement in the sympathy and synergy across cross
> platforms.  Having built stuff in this manner I am regularly pleased
> with the way that when you fix something on one platform you are much
> more likely to consider the same senario on the others.  We
> transitioned a mess of code to this style after I noticed repeated
> cases of a fix on one platform (usually a very subtle fix involving
> locks and memory management) was ignored on another because they
> hadn't yet suffered from the stress that exposed the problem.
>
> > return_type f(arg_type a1, arg_type a2)
> > {
> > ...
> > #ifdef VARIATIONA
> > ...
> > #endif
> > #ifdef VARIATIONB
> > ...
> > #endif
> > ...
> > #ifdef VARIATIONA
> > ...
> > #endif
> > #ifdef VARIATIONB
> > ...
> > #endif
> > ...
> > #ifdef VARIATIONA
> > ...
> > #endif
> > #ifdef VARIATIONB
> > ...
> > #endif
> > ...
> > #ifdef VARIATIONA
> > ...
> > #endif
> > #ifdef VARIATIONB
> > ...
> > #endif
> > ...
> > }
>
> Yeah, I've seen code like that.  And yes it is lexically very ugly.
> Consensus rarely forms about what topology of #if is right because
> porting across various features is a mess.  A mess that is be pushed
> around from one place to another.  I like to think my preference is
> for something who's structure enhances the social engineering during
> the long maintainance period.  Yes, it does create a lexically ugly,
> in your face, quality to the variation on features.
>
>  - ben
>
>


Mime
View raw message