apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: apr_mmap_t
Date Sat, 23 Nov 2002 15:29:17 GMT


On Sat, 23 Nov 2002, William A. Rowe, Jr. wrote:

> At 05:54 PM 11/20/2002, rbb@apache.org wrote:
>
> >BTW, I want to be 100% clear.  We don't use incomplete types for binary
> >compatibility.  The only reason that we use incomplete types is for
> >portability reasons.  In APR 2.0, I fully expect most of the incomplete
> >types to shrink, and for a good portion of APR to use complete types.
>
> Huh?
>
> Incomplete types have absolutely zero impact on portability, other than
> preventing authors from doing stupid things.  We've never been against
> users making stupid errors, so that can't be it :-)
>
> They are 100% about maintainability.  Cliff's particular change is the
> perfect case-in-point.

Nope.  Sorry, but you are wrong.  You may like them for maintainability
now, but the ENTIRE reason for using them is to stop users from making
stupid mistakes.

> By 2.0, I hope to have helped flesh out a reasonably portable way
> of introducing inline accessors, so the entire performance issue
> flies out the window.  Of course, when one enables the inlines, one
> binds oneself to an exact version of APR (al la HTTP's own internal
> build of APR).  If one does not use inlines, then you have complete
> freedom to use different APR versions as a dynamic library.
>
> Incomplete types were the correct initial design decision, and they
> will continue to be a good decision.

Nope.  Incomplete types were a good first start, but a combination of
complete and incomplete is the best design.

Ryan


Mime
View raw message