apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject RE: Memory Renaming (try 2)
Date Sat, 12 May 2001 04:50:42 GMT
On Sat, 12 May 2001, Sander Striker wrote:

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

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:


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.

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


   Cliff Woolley
   Charlottesville, VA

View raw message