> 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.
