William A. Rowe, Jr. wrote:
Yes, but (especially registered functions) allow you to set
up an argument type/argument list by casting a function ptr,
rather than the actual data object. This means that every
invocation of APR_FN_type_FOO will accept only a certain type,
enforcing typesafety.
Ben went to the trouble of figuring it out (brilliant!) so
I'd happily veto wrappers which don't enforce type safety.
I don't want to return to the 1.3 mod_ssl days (of a new
fn for each arg list) after we have such an elegant solution
at hand :) Take some time to grok
http://svn.apache.org/repos/asf/apr/apr-util/trunk/include/apr_optional_hooks.h
I've read apr_optional_hooks.h and looked at the underlying
implementation, and I don't see how this gains us a whole lot. What it
does seem to do is add complexity by requiring the user to declare and
then retrieve their accessor functions, and on top of that it sure
doesn't seem to be thread safe, what with its use of global variables in
apr_hooks.c with no apparent locking.
On the other hand, we've already seen these accessor macros used to
great effect in a large codebase, and I know for a fact that they make
it much much much easier to work with APR arrays. No, they do not solve
all problems, but they do improve the situation without adding a great
deal of complexity.
If I'm getting the wrong impression, and it really is far simpler to
make use of these APIs for the purpose of providing helper functions for
the APR array interface than it seems at first glance, then could you
please explain how, perhaps by sketching out how you'd see the interface
being used.
I'm especially confused at how you think this is heading to the bad old
days of a new function for each arg list, when my proposal requires
exactly two macros, and you don't ever have to declare more functions
when you want to work with more types of arrays because the type is
passed in when you invoke the macro. Now if you were arguing that
requiring the user to pass in the type is too error prone, I could see
that side of the argument, but even so I don't see how it's any more
error prone than the existing state of affairs.
-garrett
