Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 45561 invoked by uid 500); 12 May 2001 04:33:48 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 45539 invoked from network); 12 May 2001 04:33:45 -0000 From: "Sander Striker" To: Cc: "Luke Kenneth Casson Leighton" Subject: RE: Memory Renaming (try 2) Date: Sat, 12 May 2001 06:41:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010511132743.N2763@angua.rince.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > 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__ 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.