From dev-return-2131-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sat May 12 15:54:03 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 50484 invoked by uid 500); 12 May 2001 15:54:01 -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 50471 invoked from network); 12 May 2001 15:54:00 -0000 Message-ID: <004a01c0dafb$aa895fb0$6a7c1840@VAIO> From: "David Reid" To: "APR Development List" References: Subject: Re: Memory Renaming (try 2) Date: Sat, 12 May 2001 16:53:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Do we need to vote or are we happy with apr_sms_t? If we are then the new names will be... 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 apr_sms_std_create apr_sms_tracking_create Now, I'm in favour of apr_malloc apr_realloc apr_free but don't have any issues with apr_sms_malloc apr_sms_realloc apr_sms_free Once this is resolved I'll change the code. I'm planning on doing it early next week before I head to Newark on Wednesday if we can get resolution before then, unless anyone beats me to it :) BTW, I don't plan on moving the code from the memory directory unless I hear shouts and screams... david > > 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. > >