[...] >> 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
