I agree with you. For my own code I've always mimiced the java layout, and added a W to the end (for wrapper). I plan to change this to an 's' or plural version, so much am I swayed by your arguments. (That or 'Helper').
So I would suggest: org.apache.commons.java.io.Urls; org.apache.commons.java.lang.Strings org.apache.commons.javax.xml.Xmls etc etc? I'm sure it'll just start arguments about everyones favourite methodology, but people might all agree. Bay On Wed, 20 Feb 2002 [EMAIL PROTECTED] wrote: > I'm not a committer and in fact I've never used the commons util stuff yet > -- but I was looking at it recently and the only complaint I had was the > naming scheme. This was probably discussed to death before I joined the > list, but here are my two thoughts -- first, it seems as if having a package > named "util" with classes under it that have "util" in the name (i.e. > util.StreamUtils) is redundant... and second, there is already a precendent > for a naming convention for these type of classes (util classes which hold > several static methods that all have to do with a particular type of data or > type) -- specifically that is the convention used by classes like > java.util.Arrays, which is to name the class after the type that it deals > with but make it plural. In the case of the commons util package, this > would lead to changes like so: > > org.apache.commons.util.ClassUtils -> > org.apache.commons.util.Classes > org.apache.commons.util.CollectionsUtils -> > org.apache.commons.util.Collections > org.apache.commons.util.FileUtils -> org.apache.commons.util.Files > org.apache.commons.util.MapUtils -> org.apache.commons.util.Maps > org.apache.commons.util.NumberUtils -> > org.apache.commons.util.Numbers > org.apache.commons.util.ObjectUtils -> > org.apache.commons.util.Objects > org.apache.commons.util.StreamUtils -> > org.apache.commons.util.Streams > org.apache.commons.util.StringUtils -> > org.apache.commons.util.Strings > > The only one I'm not sure how to deal with is "XmlUtils", which maybe just > becomes "Xml". > > We have several packages like this here at work and it's lead to much better > naming conventions for our methods, for example we have a > com.cyveillance.io.Streams class and a com.cyveillance.io.Files class (we > went one step further and put the utility classes directly into the > appropriate subpackages the way the JDK does, but that clearly wouldn't work > for a commons-util scenario), which used to have methods like > copyStreamToStream() and copyFile() which, after we started using this > naming convention, became "Streams.copy()" and "Files.copy()" both of which > perform intuitively obvious tasks without having to have such verbose method > names as well as just feeling more "natural" since they conform to the > "Arrays.sort()" type of paradigm. > > Anyway, like I said, I'm not a committer or anything but it seems to me that > this would be the way to go with the naming convention, and since I saw the > message about a pending release I figured now was the time to speak up > before more and more code gets written using the current naming convention. > I know that changing around all of the class names is going to be a big > pain, but it'll be easier now than later if anyone feels like it's worth > doing. Oh well, there's my 2 cents. > > - > John > > -----Original Message----- > From: Daniel Rall [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 20, 2002 4:07 PM > To: [EMAIL PROTECTED] > Cc: Velocity Developers List > Subject: Commons Util 1.0 release candidate 1 > > > Prompted by Velocity's need (1.3 will use Commons Util), I've tagged > RC1, which is available here: > > http://jakarta.apache.org/builds/jakarta-commons/release/commons-util/common > s-util-1.0-rc1.jar > > Note that Commons Util is still in the sandbox (rather than in the > commons module itself). > > Dan > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
