Re: [io] questions about action items

[Ch...@dlr.de]

I second Jeremias sugested way to go! +1

Someone noted that there is no Filename notion in java.lang...
I'd say FilenameUtils would be OK, but I also thought of
NamedFileUtils.

one more embedded...

Jeremias Maerki wrote:
> 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.

Or call methods from IOUtils where sensible.

> - 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
> 

Thanks!

-- 
:) Christoph Reck


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org