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: 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. 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. --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
