from: __matthewHawthorne <[EMAIL PROTECTED]>
I think that finding a way to break out the String methods will make things
cleaner, FileUtils can just focus on Files, and the other classes can also just focus on one type.
+1 from me for this point of view.
The original FileUtils where a collection of convenience methods. Now being refactored into more generic pattern, it makes sense to cleanly separate into classes, each with its specific area of responsibility.
This fits with [lang] I think.
ObjectUtils has methods we would like to be on Object.class and StringUtils has methods we would like to be on String.class.
This plays out as the first parameter to all StringUtils methods is a String, and to ObjectUtils an Object.
Stephen
Thoughts?
Jeremias Maerki wrote:
Working with filenames often means paying attention to the path separator. java.io.File already does a pretty good job handling that. Example:
File f = new File("C:\\Temp"); f = new File(f, "foo/bar/hello.txt");
This will evaluate nicely to "C:\Temp\foo\bar\hello.txt" on a Windows machine. (Obviously the statement above doesn't make sense on a unix box. It's only an illustration.) I expect FileUtils do be equally flexible and I don't think it is right now.
The issue I'd like to point out is the following: Most of the methods in FileUtils currently have String parameters. Some have two flavors: once with java.io.File and once with String. I consider the variant with the String parameter a convenience method over the one with java.io.File parameters. In the past I've see a lot of this:
String baseDir = ... String filename = ... String fullPath = baseDir File.pathSeparatorChar filename;
where you could have written:
File baseDir = .... String filename = ... File fullPath = new File(baseDir, filename);
The second variant is less error-prone IMO. I make myself use java.io.File for every normal file or directory (non-VFS, non-URL stuff) just to avoid any OS-dependency problems. And it turned out to be a good move.
Most of the methods in FileUtils should be written based on java.io.File. But there is a problem: If these methods should also work on URLs (or maybe some kind of VFS filename), they may fail if implemented that way. So, the question is: Should we make sure that URLs (as Strings) should be supported by the methods with String parameters in FileUtils? As for VFS filenames, the VFS thing should probably have its own set of utility methods. If yes, we will have to mark methods that support URLs clearly, because not every method in FileUtils will be able to support them (cleanDirectory() for example).
Alternatively, we could create a FilenameUtils class that has some of the same methods from FileUtils but with String parameters and supporting URL syntax.
I'm not really proposing anything here because I don't have a strong opinion in either way, yet. But I'd be grateful for any thoughts.
Jeremias Maerki
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- :) Christoph Reck
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
