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 09:38:51 GMT
[...]
>> 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'.
>
> I see how you might read it that way, but at least by the current
> precedent, it's not quite right.  See the buckets code for an example:
>
> apr_bucket_heap_create
> apr_bucket_pool_create
> (etc)
>
> This doesn't mean "create an apr_bucket on the heap/pool," respectively.
> It means "create a heap/pool bucket," ie a bucket that points to stuff on
> the heap or on the pool.  The apr_bucket itself is always on the heap.
> So your model is basically correct, except that the type of thing to do an
> operation on isn't necessarily just one word.  In this case, it's
> operating on an apr_bucket and an apr_bucket_file or apr_bucket_pool at
> the same time.  So apr_sms_std_create and apr_sms_tracking_create
> would seem to be the consistent way to name these.

Glad you pointed this out, you converted me in only 15 lines :-)
I like consistency throughout the entire APR, so indeed apr_sms_std_create
and apr_sms_tracking_create are the way to go (Luke, it always amazes me
how you get this instictively right ;-).

> sms is fine with me personally, as are a few other of the options that
> have been presented.  I'm not a huge fan of just plain "memory", but
> whatever.

Ok, I think this was enough negative reactions to the 'memory' suggestion.
Time to move on. Anyone against 'sms'?

> --Cliff

Sander


Mime
View raw message