Do we need to vote or are we happy with apr_sms_t? If we are then the new names will be...
apr_sms_t apr_sms_create apr_sms_reset apr_sms_destroy apr_sms_threadsafe_lock apr_sms_threadsafe_unlock apr_sms_is_ancestor apr_sms_cleanup_register apr_sms_cleanup_unregister apr_sms_cleanup_run apr_sms_std_create apr_sms_tracking_create Now, I'm in favour of apr_malloc apr_realloc apr_free but don't have any issues with apr_sms_malloc apr_sms_realloc apr_sms_free Once this is resolved I'll change the code. I'm planning on doing it early next week before I head to Newark on Wednesday if we can get resolution before then, unless anyone beats me to it :) BTW, I don't plan on moving the code from the memory directory unless I hear shouts and screams... david > > On Fri, May 11, 2001 at 11:35:24AM +0100, David Reid wrote: > >> OK, in an effort at moving things along these names are much shorter. > >> > >> apr_sms_t > >> > >> apr_sms_create > >> apr_sms_reset > >> apr_sms_destroy > >> apr_sms_threadsafe_lock > >> apr_sms_threadsafe_unlock > >> apr_sms_is_ancestor > >> apr_sms_cleanup_register > >> apr_sms_cleanup_unregister > apr_sms_cleanup_run > > Up to here I like it :-) > > >> apr_std_sms_create > >> apr_tracking_sms_create > > > apr_sms_std_create > > apr_sms_tracking_create > > > > [clearer hierarchy. > > Ok, I can for both options see the arguments, however, I tend to > go for: > > apr_std_sms_create > apr_tracking_sms_create > > To back this up I'm going to share my view on the naming of apr > functions. I think it is done like this: > > apr_<type of thing to do an operation on>_<the operation to do> > > So, for me apr_sms_std_create would read as: do a 'standard create' > of 'sms', opposed to apr_std_sms_create reading: do a 'create' of > 'standard sms'. > > One could argue that apr_sms_create_std and apr_sms_create_tracking > are good names too, for obvious reasons. > > Basically, you guys have to take your pick (provided that you like > 'sms'): > > 1. apr_std_sms_create > apr_tracking_sms_create > > 2. apr_sms_create_std > apr_sms_create_tracking > > 3. apr_sms_std_create > apr_sms_tracking_create > > But then again, my view on apr naming could be completely off :-] > > This leads me to say that the tracking memory system was just a > quick implementation of one. I did this as an example to show how > to write one. If its going to be used I'm ok with that, but I reckon > that in the future your brand new (to be written) pool sms is going > to be the preferred tracking memory system, instead of the trivial > tracking memory system that I just called 'tracking sms' to add > to the (possible) confusion [don't you just love word soup ;-)]. > > >> apr_malloc > >> apr_realloc > >> apr_free > > > > sure about this? [not that it bothers me, one way or the other] > > I tend to agree with Luke: question yourselves, are we going to > provide apr_malloc that has a different syntax from malloc... > Opposed to providing apr_sms_malloc, etc, which are more consistent > and don't lead to any confusion (I hope). On the other hand, it > saves you four characters of typing in every call _and_ you show > users that you are serious: every single piece of memory should > come from a sms. > > >> Well, thoughts? > > > > like. > > Apart from the comments stated above: I like too :-) > > Sander > > PS. apr_sms_threadsafe_lock and apr_sms_threadsafe_unlock are still > in there and there names are confusing. We came up with those > while in a discussion on accessing memory from multiple threads. > Ofcourse this can be made more general and maybe should therefor > be named apr_sms_lock and apr_sms_unlock. _But_ first we should > discuss what this code should really do and what kind of syntax > the functions should have. So guys, when you have some moments > to spare, please review the sms code (currently under apr/memory) > and start commenting. > >
