On Fri, 29 Oct 2004 14:48:32 -0400, Henri Yandell <[EMAIL PROTECTED]> wrote: > Okay, time to put this baby to sleep (and I wish that was a metaphor! > he's always hungry). > > A first question to ask is, what is the class FilenameUtils for? The > immediate answer is utilities for filenames. ie) the Wildcard code. > > Here's the list of methods in FilenameUtils, with comments: > > // 1) These 3 should be deleted. They are file based, not filename based. > boolean fileExists(String fileName) > void fileDelete(String fileName) > void mkdir(String dir) > > // 2) These are all simple with Lang StringUtils; but acceptable as semantic. > String removeExtension(String filename) > String getExtension(String filename) > String removePath(String filepath) > String getPath(String filepath) > // 2.1) Not convinced these two should exist. People should use > StringUtils if they're not > // dealing with their own file-system. > String removePath(String filepath,char fileSeparatorChar) > String getPath(String filepath,char fileSeparatorChar) > > // 3) This one does make sense, but it's UNIX specific currently. It's > the one that should have a fileSeparatorChar argument. > String normalize(String path) > > // 4) Less compelling, but seems acceptable. It works on MS and UNIX. > String catPath(String lookupPath, String path) > > // 5) Not impressed by this one. I'm not convinced it would actually > work. catPath relies on it. > int indexOfLastPathSeparator(String path) > > // 6) Not a huge fan of this method. baseFile is an optional parameter > by looks of it; it lacks a good use-case as an example; but it is at > least filename based to a certain extent. > File resolveFile(File baseFile, String filename) > > Looking at the above; I'd like to kill 1), 2.1), 4) and 5) and > consider the death of 6).
All OK with me. > 7) There are also two private methods. internalize and externalize. > Nothing uses the latter and the former is used by getExtension only > and should be inlined into its code. There is also an unused > INTERNAL_SEPARATOR variable that needs killing. I added these just recently. The reason I added internalize() as a separate method, rather than inlining the code, was because the comment was made that our path and filename manipulation code should do something similar to what java.io.File does. That is, it should convert to a standard internal form, so that manipulation can be performed the same way regardless of the original file system. That's what internalize() does. As you noted, it turned out that this affected only getExtension() (and hence removeExtension() indirectly). Nevertheless, I felt it was worth leaving the method there, since it's likely that future methods would want to use it. I created externalize() only as the inverse of internalize(), again for future use, since it turned out that it wasn't needed in the existing code. As for INTERNAL_SEPARATOR, I added that simply because I see that as the parallel to File.fileSeparator, just as INTERNAL_SEPARATOR_CHAR is the parallel to File.separatorChar. Feel free to remove the unused stuff if you think it would be better that way. I'd prefer to leave internalize(), though, if for no other reason than to promote its use when new methods are added that should be working in that same manner. -- Martin Cooper > > So, any disagreements to the above? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
