On 31.07.2003 01:32:12 __matthewHawthorne wrote: > 2) Extract code from IOUtils to CopyUtils? > > Should I go ahead and start this?
I don't have a strong opinion on this point, but I guess a smaller IOUtils won't hurt. So, go ahead if you agree with this move (unless someone else objects). > 3) FileUtils: This class is a big mess ATM. We need to clean it up. > > I believe FileUtils was somehow involved in the huge > static/final/inheritance debate. Are there any ideas as to how to > approach the cleanup of this class? Should the String methods be > deprecated and moved into another class? This requires a good plan. Well, IO is not released, so we have some flexibility here. I'd do the following: - Deprecate the existing String methods (we will remove them before the release). - For FileUtils: Start by writing (or fixing/improving) test cases for methods such as: removeExtension(File), getExtension(File), removePath(File), getPath(File) etc. Try to implement them based on java.io.File where possible because this class can already handle mixed path separators (C:\Temp/foo/myfile.txt). Maybe we need to reimplement that behaviour for our methods. - Create a new class FilenameUtils (unless someone has a better idea, but that name says it all). - FilenameUtils methods should call the ones from FileUtils whenever possible. - Your idea about the different FilenameUtils implementations may be worth trying out. ...I don't want to give you any instructions. Apply common sense, apply what you read in the discussions (no private constructors, no finals etc. See lang's DEVELOPER's GUIDE). Bring in your own ideas. What we need is a homogenous set of classes that provide some often needed functions. The package should mature over time. We can always adjust. If someone objects to a change we can easily revert. My participation here is simply to push the package forward a bit. I don't want to take the lead or something. Keep the patches coming. I'd be glad to apply them. I don't have so much time working on IO but I will as time allows. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
