a good point, well made. worth considering changing the names, i'd say.
BTW Daniel - am i right in assuming that the release candidate is based on the sandbox CVS HEAD? (at the moment, i think that the sandbox build has some missing dependencies. i could probably take a look at fixing it if you like.) - we're missing information about utils on the commons web site. a single pithy summary paragraph is what's needed for the components page. a page full would allow a link from the side bar. if we could pull together the required information on the mailing list, i could probably make the change to the site. - robert On Wednesday, February 20, 2002, at 09:34 PM, [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]. > org> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]. > org> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
