renaming apr_filetype enum entries
As discussed back in June enum names in the apr_filetype_e entry are polluting the APR_ defines namespace and it's hard to grok what APR_REG means when it's used in the code. I've finally started to work on these as I'm finishing the perl glue manpage for the apr_finfo interface. So any objecttions to the s/APR_/APR_FILETYPE_/ rename? In order to support older versions one will need to also provide a compat layer: #ifndef APR_FILETYPE_NOFILE #define APR_FILETYPE_NOFILE APR_NOFILE #endif #ifndef APR_FILETYPE_REG #define APR_FILETYPE_REG APR_REG #endif #ifndef APR_FILETYPE_DIR #define APR_FILETYPE_DIR APR_DIR #endif #ifndef APR_FILETYPE_CHR #define APR_FILETYPE_CHR APR_CHR #endif #ifndef APR_FILETYPE_BLK #define APR_FILETYPE_BLK APR_BLK #endif #ifndef APR_FILETYPE_PIPE #define APR_FILETYPE_PIPEAPR_PIPE #endif #ifndef APR_FILETYPE_LNK #define APR_FILETYPE_LNK APR_LNK #endif #ifndef APR_FILETYPE_SOCK #define APR_FILETYPE_SOCKAPR_SOCK #endif #ifndef APR_FILETYPE_UNKFILE #define APR_FILETYPE_UNKFILE APR_UNKFILE #endif Any objections? From what I understood, this should be applied only to the HEAD. Is that correct? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
renaming apr_file_permissions defines
and the rename of apr_file_permissions group: s/APR_/APR_FILEPROT_/ with backcompat as following: #ifndef APR_FILEPROT_USETID #define APR_FILEPROT_USETID APR_USETID #endif #ifndef APR_FILEPROT_UREAD #define APR_FILEPROT_UREAD APR_UREAD #endif #ifndef APR_FILEPROT_UWRITE #define APR_FILEPROT_UWRITE APR_UWRITE #endif #ifndef APR_FILEPROT_UEXECUTE #define APR_FILEPROT_UEXECUTE APR_UEXECUTE #endif #ifndef APR_FILEPROT_GSETID #define APR_FILEPROT_GSETID APR_GSETID #endif #ifndef APR_FILEPROT_GREAD #define APR_FILEPROT_GREAD APR_GREAD #endif #ifndef APR_FILEPROT_GWRITE #define APR_FILEPROT_GWRITE APR_GWRITE #endif #ifndef APR_FILEPROT_GEXECUTE #define APR_FILEPROT_GEXECUTE APR_GEXECUTE #endif #ifndef APR_FILEPROT_WSTICKY #define APR_FILEPROT_WSTICKYAPR_WSTICKY #endif #ifndef APR_FILEPROT_WREAD #define APR_FILEPROT_WREAD APR_WREAD #endif #ifndef APR_FILEPROT_WWRITE #define APR_FILEPROT_WWRITE APR_WWRITE #endif #ifndef APR_FILEPROT_WEXECUTE #define APR_FILEPROT_WEXECUTE APR_WEXECUTE #endif #ifndef APR_FILEPROT_OS_DEFAULT #define APR_FILEPROT_OS_DEFAULT APR_OS_DEFAULT #endif #ifndef APR_FILEPROT_FILE_SOURCE_PERMS #define APR_FILEPROT_FILE_SOURCE_PERMS APR_FILEPROT_FILE_SOURCE_PERMS #endif -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
renaming apr_file_open_flags group defines
This group wasn't discussed before, but it suffers from the same problem. #define APR_READ 0x1 /** Open the file for reading */ #define APR_WRITE 0x2 /** Open the file for writing */ #define APR_CREATE 0x4 /** Create the file if not there */ Not sure what's the best prefix here. Is APR_OPEN_ good? APR_OPEN_READ, APR_OPEN_WRITE, ... -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_file_permissions defines
At 07:53 PM 9/17/2004, you wrote: and the rename of apr_file_permissions group: s/APR_/APR_FILEPROT_/ Veto - defer for 2.0
Re: renaming apr_filetype enum entries
At 09:05 PM 9/17/2004, William A. Rowe, Jr. wrote: At 06:54 PM 9/17/2004, you wrote: So any objecttions to the s/APR_/APR_FILETYPE_/ rename? Veto - defer for 2.0 I don't object to the new names, but find it pretty absurd to start deprecating interfaces the month we roll out 1.0. Bill
Re: renaming apr_file_open_flags group defines
At 08:34 PM 9/17/2004, you wrote: This group wasn't discussed before, but it suffers from the same problem. #define APR_READ 0x1 /** Open the file for reading */ #define APR_WRITE 0x2 /** Open the file for writing */ #define APR_CREATE 0x4 /** Create the file if not there */ Not sure what's the best prefix here. Is APR_OPEN_ good? APR_OPEN_READ, APR_OPEN_WRITE, ... Veto - defer for 2.0 About this group - smakes sense to me unless these flags are 'generic', e.g. apply-to other. And no, APR_OPEN_ isn't ideal, but APR_FILE_OPEN_ would be.
Re: renaming apr_filetype enum entries
William A. Rowe, Jr. wrote: At 09:05 PM 9/17/2004, William A. Rowe, Jr. wrote: At 06:54 PM 9/17/2004, you wrote: So any objecttions to the s/APR_/APR_FILETYPE_/ rename? Veto - defer for 2.0 I don't object to the new names, but find it pretty absurd to start deprecating interfaces the month we roll out 1.0. You mean, I've missed the train? Well, we are about to freeze the mod_perl 2 API, and we would like to have non-ambiguous constants. So I'm not sure how to proceed from here. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
Stas Bekman wrote: William A. Rowe, Jr. wrote: At 09:05 PM 9/17/2004, William A. Rowe, Jr. wrote: At 06:54 PM 9/17/2004, you wrote: So any objecttions to the s/APR_/APR_FILETYPE_/ rename? Veto - defer for 2.0 I don't object to the new names, but find it pretty absurd to start deprecating interfaces the month we roll out 1.0. You mean, I've missed the train? Well, we are about to freeze the mod_perl 2 API, and we would like to have non-ambiguous constants. So I'm not sure how to proceed from here. Well, the APR_ namespace is non-ambiguously APR's, and APR itself can ensure sanity within that namespace - what more is required? Personally, I think it's good that APR's constant names aren't needlessly bloated in length. Max.
Re: renaming apr_filetype enum entries
Max Bowsher wrote: Stas Bekman wrote: William A. Rowe, Jr. wrote: At 09:05 PM 9/17/2004, William A. Rowe, Jr. wrote: At 06:54 PM 9/17/2004, you wrote: So any objecttions to the s/APR_/APR_FILETYPE_/ rename? Veto - defer for 2.0 I don't object to the new names, but find it pretty absurd to start deprecating interfaces the month we roll out 1.0. You mean, I've missed the train? Well, we are about to freeze the mod_perl 2 API, and we would like to have non-ambiguous constants. So I'm not sure how to proceed from here. Well, the APR_ namespace is non-ambiguously APR's, and APR itself can ensure sanity within that namespace - what more is required? Personally, I think it's good that APR's constant names aren't needlessly bloated in length. What's exactly APR itself? You mean it can look in the mirror and smile at how beautiful it is? And never leave the house? APR can be judged by how useful it is in the projects it's used. It's useless on its own. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
At 10:03 PM 9/17/2004, Max Bowsher wrote: Stas Bekman wrote: William A. Rowe, Jr. wrote: I don't object to the new names, but find it pretty absurd to start deprecating interfaces the month we roll out 1.0. You mean, I've missed the train? Well, we are about to freeze the mod_perl 2 API, and we would like to have non-ambiguous constants. So I'm not sure how to proceed from here. If you release mod_perl with those identifiers, you will be bound to APR 1.1 - and httpd 2.1-dev is keyed to APR 1.0 at this time. You must use APR 1.0 constants to be compatible with 2.2 when it's released unless httpd adopts an APR 1.1. Remember, new features get a minor version bump from now on, not just another subversion bump. See: http://apr.apache.org/versioning.html Well, the APR_ namespace is non-ambiguously APR's, and APR itself can ensure sanity within that namespace - what more is required? Legibility is important too, so I've agreed with Stas, in principal, with his renaming suggestions. Unfortuantely, I didn't see enough other people comment about them to adopt any of the proposed changes, for or against :( Personally, I think it's good that APR's constant names aren't needlessly bloated in length. It's nice to have shorthand, and amusing that most Java developers consider the terminal width to be 96 characters these days :) I wouldn't consider the longhand needlessly bloated, however. Bill
