On Sat, 23 Nov 2002, William A. Rowe, Jr. wrote:
> At 05:54 PM 11/20/2002, [EMAIL PROTECTED] 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
