So basically we're arguing over the semantics of the name! I'll add the code as _put and you guys can change the name to _fluffy_pink_rabbits if it'll make you feel better.
david ----- Original Message ----- From: "Greg Stein" <[EMAIL PROTECTED]> To: "APR Development List" <dev@apr.apache.org> Sent: Thursday, April 19, 2001 12:05 AM Subject: Re: apr_dso_make?? > 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/ >
