From dev-return-11951-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Mon Jun 07 14:21:18 2004 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 69291 invoked from network); 7 Jun 2004 14:21:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 7 Jun 2004 14:21:17 -0000 Received: (qmail 52346 invoked by uid 500); 7 Jun 2004 14:21:18 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 52213 invoked by uid 500); 7 Jun 2004 14:21:16 -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 52099 invoked by uid 99); 7 Jun 2004 14:21:15 -0000 Errors-To: Message-Id: <6.1.0.6.2.20040604143624.04f5dbc8@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 07 Jun 2004 09:02:19 -0500 To: Stas Bekman From: "William A. Rowe, Jr." Subject: Re: documented 1.0 showstoppers Cc: Jeff Trawick , dev@apr.apache.org In-Reply-To: <40C0C43B.8090709@stason.org> References: <40BEFCF9.8010608@attglobal.net> <40C0C43B.8090709@stason.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N APR_FINFO_ seems wrong below - does APR_FILEPROT_ make sense? At 01:49 PM 6/4/2004, Stas Bekman wrote: >Jeff Trawick wrote: > >Why is that everybody suddenly has the time to go on huge threads pushing for 1.0 release and totally ignoring efforts to make a solid 1.0 first. How many times do I have to ask whether my suggestion for making the API more sensible before I'll get some feedback? Several people +1'd that this needs to be done *before* 1.0 is released. and since then I'm talking to a wall :( > >Here is at least one issue that I'm talking about: > >Subject: Re: enum and defines naming > >William A. Rowe, Jr. wrote: >> At 08:02 PM 5/21/2004, Stas Bekman wrote: >> >>> Before apr 1.0 is cast in stone any chance public enums and defines will >>> get sensible names? It all looks nice in the declaration but in the code, >>> one needs to scratch the head to figure out what APR_REG means. Why not >>> have /^APR_FILETYPE_/ prefix? APR_FILETYPE_REG requires no head >>> scratching when reading the code and won't collide with some other enum >>> with a totally different functionality. >> >> >> +1 >> >> >>> Same goes for defines, for example: There are all related to files, why >>> pollute the namespace with such short names and not fix them to have a >>> sensible prefix similar to above suggestion? /^APR_FILETYPE_/ as in >>> APR_FILETYPE_UREAD. >> >> >> >> +1 again. This is why 1.0 isn''t ready just yet, IMHO :) > >Thanks. So what's the next step? How one performs this kind of rename? I have >seen that done with functions, not sure how does it work for enums. I guess >defines are the same as functions. > >Should it be s/APR_/APR_FILETYPE_/ and s/APR_/APR_FINFO_/ or something else? >Like so? > >typedef enum { > APR_FILETYPE_NOFILE = 0, /**< no file type determined */ > APR_FILETYPE_REG, /**< a regular file */ > APR_FILETYPE_DIR, /**< a directory */ > APR_FILETYPE_CHR, /**< a character device */ > APR_FILETYPE_BLK, /**< a block device */ > APR_FILETYPE_PIPE, /**< a FIFO / pipe */ > APR_FILETYPE_LNK, /**< a symbolic link */ > APR_FILETYPE_SOCK, /**< a [unix domain] socket */ > APR_FILETYPE_UNKFILE = 127 /**< a file of some other unknown type */ >} apr_filetype_e; > > > >#define APR_FINFO_UREAD 0x0400 /**< Read by user */ >#define APR_FINFO_UWRITE 0x0200 /**< Write by user */ >#define APR_FINFO_UEXECUTE 0x0100 /**< Execute by user */ > >#define APR_FINFO_GREAD 0x0040 /**< Read by group */ >#define APR_FINFO_GWRITE 0x0020 /**< Write by group */ >#define APR_FINFO_GEXECUTE 0x0010 /**< Execute by group */ > >#define APR_FINFO_WREAD 0x0004 /**< Read by others */ >#define APR_FINFO_WWRITE 0x0002 /**< Write by others */ >#define APR_FINFO_WEXECUTE 0x0001 /**< Execute by others */ > > > > >-- >__________________________________________________________________ >Stas Bekman JAm_pH ------> Just Another mod_perl Hacker >http://stason.org/ mod_perl Guide ---> http://perl.apache.org >mailto:stas@stason.org http://use.perl.org http://apacheweek.com >http://modperlbook.org http://apache.org http://ticketmaster.com