apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: Memory Renaming (try 2)
Date Sat, 12 May 2001 15:53:14 GMT
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.
>
>



Mime
View raw message