commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From m..@apache.org
Subject cvs commit: jakarta-commons/collections DEVELOPERS-GUIDE.html
Date Wed, 03 Jul 2002 02:34:09 GMT
mas         2002/07/02 19:34:09

  Modified:    collections DEVELOPERS-GUIDE.html
  Log:
  Update naming convention to be a bit more relaxed on decorator method names
  (e.g. allow unmodifiableBuffer as an allowed decorator name)
  
  Revision  Changes    Path
  1.2       +15 -8     jakarta-commons/collections/DEVELOPERS-GUIDE.html
  
  Index: DEVELOPERS-GUIDE.html
  ===================================================================
  RCS file: /home/cvs/jakarta-commons/collections/DEVELOPERS-GUIDE.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DEVELOPERS-GUIDE.html	29 Jun 2002 03:49:01 -0000	1.1
  +++ DEVELOPERS-GUIDE.html	3 Jul 2002 02:34:09 -0000	1.2
  @@ -80,13 +80,20 @@
   interface</li>
   </ul>
   
  -<p>Where the method in a Utils class is a decorator, the naming pattern
  -yyyedXxx shall be used, such as <code>synchronizedMap(Map)</code> or
  -<code>predicatedSet(Set)</code>.  Typically, these decorators should be
  -implemented as non-public, static, inner classes; however, if warranted due to
  -maintenance or other reasons, these decorator classes may be moved to top-level
  -classes in a subpackage.  The naming of such a subpackage should be discussed
  -and agreed upon on the developers mailing list.</p>
  +<p>Where the method in a Utils class is a decorator, the name shall consist of
  +an adjective followed by the collection type.  Typically such adjective is
  +formed by appending an -ed suffix (meaning "having"/"characterized by") to the
  +word describing the type of decorator.  For example,
  +<code>synchronizedMap(Map)</code> or <code>predicatedSet(Set)</code>.
  +Occasionally, such construct is awkward and a more suitable adjective can be
  +used instead.  For example, <code>lazyList</code>,
  +<code>unmodifiableList</code>.</p>
  +
  +<p>Typically, these decorators should be implemented as non-public, static,
  +inner classes; however, if warranted due to maintenance or other reasons, these
  +decorator classes may be moved to top-level classes in a subpackage.  The
  +naming of such a subpackage should be discussed and agreed upon on the
  +developers mailing list.</p>
   
   </body>
   </html>
  
  
  

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message