You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by __matthewHawthorne <mh...@alumni.pitt.edu> on 2003/07/31 01:32:12 UTC
[io] questions about action items
I have time to do some work, so, in looking at the action items, I have
a few questions...
1) Compress - Move the compress sub-package out of IO - READY
What does this mean exactly? Where is it being moved to?
2) Extract code from IOUtils to CopyUtils?
Should I go ahead and start this?
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] questions about action items
Posted by 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
Re: [io] questions about action items
Posted by 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
Re: [io] questions about action items
Posted by Jeremias Maerki <de...@greenmail.ch>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] questions about action items
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 30 Jul 2003, __matthewHawthorne wrote:
> I have time to do some work, so, in looking at the action items, I have
> a few questions...
>
> 1) Compress - Move the compress sub-package out of IO - READY
>
> What does this mean exactly? Where is it being moved to?
Somewhere else :)
Reason for it not being moved yet is due to exactly your question. Where
do we stick it and what do we name that.
I'll leave the other questions for Jeremias.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org