httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j..@hyperreal.org
Subject cvs commit: apache-1.3 STATUS
Date Fri, 03 Apr 1998 13:37:42 GMT
jim         98/04/03 05:37:42

  Modified:    .        STATUS
  Log:
  Clear up some points about prefixes
  
  Revision  Changes    Path
  1.258     +10 -10    apache-1.3/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /export/home/cvs/apache-1.3/STATUS,v
  retrieving revision 1.257
  retrieving revision 1.258
  diff -u -r1.257 -r1.258
  --- STATUS	1998/04/03 13:29:03	1.257
  +++ STATUS	1998/04/03 13:37:41	1.258
  @@ -177,7 +177,8 @@
         apache-1.3/src/test/rename/rename.cf file as the configuration for the
         renaming. The used prefix or prefixes are configureable in the file,
         too. But we have to additionally vote on them in the next point.
  -      Votes: Ralf +1
  +      Votes: Ralf +1, Jim +1 (on the source-level renaming for
  +      1.3b6 and 1.3.0; how is still up for debate :) )
   
       * Use consistant prefixes for the renaming; suggestions:
   
  @@ -255,15 +256,14 @@
                 keep this straight far outweighs any gain this
                 could give. 
               - Jim: We should make some sort of logical effort to
  -              keep things straight and organized. Taken to it's
  -              logical conclusion, this argument could be used to
  -              keep all variable and function names to 6 chars or
  -              less to cut down on all that nasty typing. So
  -              instead of something like 'lingering_close', we
  -              would use something like 'lcs' :) We should make
  -              some effort to make our code reader and maintainer
  -              friendly, because we aren't, and won't be, the only
  -              one's to maintain this.
  +              keep things straight and organized. This does nothing
  +	      to indicate in the code what is API, and what
  +	      isn't. In my mind, we should use prefixed not JUST
  +	      to prevent namespace collisions, but also to
  +	      "define" the type function. The very fact that we
  +	      _have_ the above different "types" of functions
  +	      indicates to me that we should have some logical
  +	      namespace for them.
               - Ralf: I agree with Jim that although the short ap_
                 prefix is good for API functions, it shouldn't be
                 used for all functions. That's too less. Some
  
  
  

Mime
View raw message