apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: Opaque types [was apr_mmap_t]
Date Mon, 25 Nov 2002 03:24:54 GMT

> >I thought of this a few months ago, but I have been sitting on it while we
> >try to get 1.0 out the door.  This is my vision for how APR 2.0 will be
> >implemented (I was going to propose it to the list after 1.0 had been
> >released).  This makes the API cleaner and smaller, because many of the
> >accessor functions can cleanly be deprecated (Think all of the userdata
> >functions).  It also solves a lot of problems with apr_proc_t's on
> >Windows, where we don't have anyplace to store OS specific information.
> >
> >When I said a few days ago that I had hoped that many of the incomplete
> >types would go away in APR 2.0, this is what I meant.  I don't think we
> >should re-write APR 1.0 now, but if you are going to change MMAPs, then
> >please let's do it the right way.
>
> Your "one right way" seems to be at odds with other's interpretations.

Nobody has said that yet.  In fact, your response is the first one since I
posted the idea.  Regardless, the statement stands.  If you are going to
rewrite MMAPS, then please let's do it the right way.  Whether that way is
what I suggested or not is immaterial.

> I'm not arguing that exposing incomplete types wouldn't speed up APR.
> In fact, well written accessors that are inline'able on all modern compilers
> would be a beautiful thing.  They would work only for 'private' copies of
> the apr library, since the app becomes permanently bound to the explicit
> version installed at the time you build it.  That would be fine by httpd and

There are very few compilers that can inline functions that are in
separate libraries.  In fact, I don't currently know of any.

> other consumers who don't mind building APR themselves, or for apps
> that are built via one of the packaging tools that tracks dependencies,
> and will rebuild the entire slew of dependent packages when a new
> version of APR is installed.
>
> Of course, this won't work for deployment across different platforms.

I can't understand this statement at all.  Deployment across different
platforms doesn't make sense in APR.

> By committing to unwrapping all of the opaque types, you seem hell
> bent on ensuring we forever break binary compatibility.  Opaque types

Again, what in the world are you talking about?  The design that I
suggested actually makes binary compatibility one of it's core goals.  I
am a VERY strong believer in binary compat for libraries, so this
statement makes little to no sense.  If you look at the design, you will
see that it splits the structure into two parts:  1)  The logical
component and 2)  The OS specific component.  Because there is an
incomplete type in the middle of the structure, an allocator is still
required to actually create an instance of a type.  That means that binary
compat is easy to get, assuming all new fields are added at the end of the
structure.  The only time you will get into trouble is if somebody passes
the structure itself instead of a pointer to the structure.  Yes, binary
compat would be broken between 1.0 and 2.0, but we never said that was a
goal.

> are goodness for versioning, portability, and extensions of the APR
> library to other languages (e.g. tcl, perl, java etc, especially those
> with OO schemas).  We (you especially) did a passable job of making
> APR map very well to OO schemas.  Please consider their benefits
> of opaque types before we make plans to wipe them out.

Pay very close attention please.  Using a combination of complete and
incomplete types allows for all of the advantages of both, with very few
disadvantages.

The idea of wrapping APR in an OO language has never been called out as a
goal, but even if it is made into a goal, splitting the types into a
combination of complete and incomplete will not hurt that goal at all.

Ryan



Mime
View raw message