apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: Memory Renaming (try 2)
Date Sat, 12 May 2001 04:41:23 GMT
> 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.


Mime
View raw message