On Wed, Apr 18, 2001 at 06:47:21PM +0100, David Reid wrote: > Remind me again, why aren't we just going to add apr_dso_os_put (or whatever > combination of the bits in the correct order is these days) and the _get > version to use apr_os_dso_t's? That *would* keep us in line with the rest > of the APR API wouldn't it?
We discussed this a while back. The "put" forms actually don't make a lot of sense. How do you make an empty FOO, so that you can put a native FOO into it? As a result, the useful form is to "make" a FOO using a native object. Hunh. Actually, it looks like the "put" forms are misnamed. They create an object, rather than putting a native handle into an existing object. Per the previous conversation, I'm +1 on renaming the "put" forms to "make". The bootstrap problem of how to get a FOO means that "put" just isn't a useful abstraction. Not to mention it leads to confusion like what we just saw: you put into an existing apr_dso_handle_t, but put for files will create a new file object. Ooky. Oh, crap. I just looked at unix/locks.c::apr_os_lock_put(). It expects the user to do the whole "set to NULL before calling" thing. Damn, that style was a source of bugs to no end (recall that file_open worked that way for a while and bit us all the time). I think it is confusing to do a "put" into an object. That can lead to resource leaks (what happens to the previous native FOO?). I think it would be best for us to drop all the "put" stuff, and stick with "get" and "make". Thoughts? Cheers, -g -- Greg Stein, http://www.lyra.org/
