> A first question to ask is, what is the class FilenameUtils for? The > immediate answer is utilities for filenames. ie) the Wildcard code.
Hmm, there seems to be a difference of view over what FilenameUtils is about. You have evaluated method based on whether they manipulate filenames. I was expecting there to also be methods in there that do file operations, but without creating a File class yourself. I can cope if we want to exclude this second group of methods, but we need to clearly scope the class. > // 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) Thus, these are fine for me (depending on the scope of the class), except for the names which should match exactly the File methods - exists, delete, mkdirs. > // 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) These seem fine as filename manipulation methods, avoiding unix/windows style errors. Should the removePath method be getName (ie positive rather than negative)? > // 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) These seem bad. > // 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) Needs fixing > // 4) Less compelling, but seems acceptable. It works on MS and UNIX. > String catPath(String lookupPath, String path) I dislike the name. How about merge() > // 5) Not impressed by this one. I'm not convinced it would actually > work. catPath relies on it. > int indexOfLastPathSeparator(String path) Doesn't getPath() also need this same concept. Sounds like some refactoring here > // 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) This just looks very odd > 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 would vote to make them public. separatorsToUnix(), separatorsToWindows(), plus separatorsToSystem() > So, any disagreements to the above? ;-) Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
