You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/07/31 13:57:10 UTC
[io] Deprecate CopyUtils
I have been looking at adding methods to IOUtils/CopyUtils, to handle
additional types and to fix some holes.
The net result is a realisation that the CopyUtils class was a poor creation
(and it may even have been my idea!).
- CopyUtils implements various methods that write byte[] and String to
stream/writer but to this inefficiently via other writers/streams.
- null handling is unclear.
- the toXxx methods on IOUtils are strongly related to CopyUtils yet they
are on a different class (they are the read() operations)
- it is not logical to look on a 'copy' class to find a method when I just
want to 'write' data (write a string/byte[] to file is not a copy operation
in most peoples minds.)
So, I propose the following:
CopyUtils deprecated, methods moved to IOUtils.
Write methods (string/byte[] to stream) are renamed to write(...)
Copy methods (stream to stream) stay named as copy(...)
The write methods will also change implementation to handle null
string/byte[] and to be more efficient.
The main downside is that it annoys users who are using CopyUtils. However,
it does seem to be better to fix the issue and get the right API.
Alternatives would include ReaderUtils, WriterUtils, InputStreamUtils,
OutputStreamUtils, but then where do the actual copy methods go. Plus too
much breaking up can be troublesome for users too. This strategy of IOUtils
for low level streams/readers/writers and FileUtils for higher level files
and FilenameUtils for even higher level seems to work well in my mind.
If there are no objections I will commit these changes....
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Deprecate CopyUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
The current setup really only exists because the methods were badly named in
the first place.
The question is basically whether having write and copy methods in one
class, but read in another makes sense, especially when the write methods
are in a class named CopyUtils!
Stephen
----- Original Message -----
From: "Jeremias Maerki" <de...@greenmail.ch>
> Sorry for the massive delay. You have some points. Still, I'm reluctant
> to merge CopyUtils and IOUtils again because IOUtils will become huge.
> Splitting the whole thing into a number of classes will provide
> headaches about what to put where and who to name it. It's not always
> clear where something should be put. If the thing is mixed up too much
> noone will find the method he/she needs. Having said that the one big
> IOUtils isn't such a bad idea but has similar problems. But in the end
> my gut feeling is that the current setup is not that bad. Read that as a
> -0.
>
> Personally, I have no problem with changing APIs but other people are
> extremely sensitive about it.
>
> I'm no big help here, I know, but just so you get another opinion.
>
> On 31.07.2004 13:57:10 Stephen Colebourne wrote:
> > I have been looking at adding methods to IOUtils/CopyUtils, to handle
> > additional types and to fix some holes.
> >
> > The net result is a realisation that the CopyUtils class was a poor
creation
> > (and it may even have been my idea!).
> >
> > - CopyUtils implements various methods that write byte[] and String to
> > stream/writer but to this inefficiently via other writers/streams.
> > - null handling is unclear.
> > - the toXxx methods on IOUtils are strongly related to CopyUtils yet
they
> > are on a different class (they are the read() operations)
> > - it is not logical to look on a 'copy' class to find a method when I
just
> > want to 'write' data (write a string/byte[] to file is not a copy
operation
> > in most peoples minds.)
> >
> > So, I propose the following:
> > CopyUtils deprecated, methods moved to IOUtils.
> >
> > Write methods (string/byte[] to stream) are renamed to write(...)
> > Copy methods (stream to stream) stay named as copy(...)
> >
> > The write methods will also change implementation to handle null
> > string/byte[] and to be more efficient.
> >
> > The main downside is that it annoys users who are using CopyUtils.
However,
> > it does seem to be better to fix the issue and get the right API.
> >
> >
> > Alternatives would include ReaderUtils, WriterUtils, InputStreamUtils,
> > OutputStreamUtils, but then where do the actual copy methods go. Plus
too
> > much breaking up can be troublesome for users too. This strategy of
IOUtils
> > for low level streams/readers/writers and FileUtils for higher level
files
> > and FilenameUtils for even higher level seems to work well in my mind.
> >
> > If there are no objections I will commit these changes....
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Deprecate CopyUtils
Posted by Jeremias Maerki <de...@greenmail.ch>.
Sorry for the massive delay. You have some points. Still, I'm reluctant
to merge CopyUtils and IOUtils again because IOUtils will become huge.
Splitting the whole thing into a number of classes will provide
headaches about what to put where and who to name it. It's not always
clear where something should be put. If the thing is mixed up too much
noone will find the method he/she needs. Having said that the one big
IOUtils isn't such a bad idea but has similar problems. But in the end
my gut feeling is that the current setup is not that bad. Read that as a
-0.
Personally, I have no problem with changing APIs but other people are
extremely sensitive about it.
I'm no big help here, I know, but just so you get another opinion.
On 31.07.2004 13:57:10 Stephen Colebourne wrote:
> I have been looking at adding methods to IOUtils/CopyUtils, to handle
> additional types and to fix some holes.
>
> The net result is a realisation that the CopyUtils class was a poor creation
> (and it may even have been my idea!).
>
> - CopyUtils implements various methods that write byte[] and String to
> stream/writer but to this inefficiently via other writers/streams.
> - null handling is unclear.
> - the toXxx methods on IOUtils are strongly related to CopyUtils yet they
> are on a different class (they are the read() operations)
> - it is not logical to look on a 'copy' class to find a method when I just
> want to 'write' data (write a string/byte[] to file is not a copy operation
> in most peoples minds.)
>
> So, I propose the following:
> CopyUtils deprecated, methods moved to IOUtils.
>
> Write methods (string/byte[] to stream) are renamed to write(...)
> Copy methods (stream to stream) stay named as copy(...)
>
> The write methods will also change implementation to handle null
> string/byte[] and to be more efficient.
>
> The main downside is that it annoys users who are using CopyUtils. However,
> it does seem to be better to fix the issue and get the right API.
>
>
> Alternatives would include ReaderUtils, WriterUtils, InputStreamUtils,
> OutputStreamUtils, but then where do the actual copy methods go. Plus too
> much breaking up can be troublesome for users too. This strategy of IOUtils
> for low level streams/readers/writers and FileUtils for higher level files
> and FilenameUtils for even higher level seems to work well in my mind.
>
> If there are no objections I will commit these changes....
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] Deprecate CopyUtils
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
+1 on post.
///:-)
-1 on politics.
///8-(
At 08:12 AM 8/1/2004, you wrote:
>But again, making the API better
>seems to be the right approach in this case.
>
>
>Steven Caswell
>Sun Certified Java Programmer
>steve@mungoknotwise.com
>["War is .... John Stuart Mill]
Michael McGrady
Sun Certified Java Programmer
Hume, Kant; Hegel, can.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [io] Deprecate CopyUtils
Posted by Steven Caswell <st...@mungoknotwise.com>.
I'm not an io committer, so this is just my $.02. I usually agree that
significant API changes aren't the best approach, but in this case I think
it is better to get it right now. I've used CopyUtils in a couple of places,
and I would not get heartburn having to change my code knowing the API was
changing for the better. Granted I have only a few changes to make, and I
might feel differently if I had bunches. But again, making the API better
seems to be the right approach in this case.
Steven Caswell
Sun Certified Java Programmer
steve@mungoknotwise.com
"War is an ugly thing, but not the ugliest of things. The decayed and
degraded state of moral and patriotic feeling that thinks that nothing is
worth war is much worse. The person who has nothing for which he is willing
to fight, nothing which is more important than his own personal safety, is a
miserable creature and has no chance of being free unless made and kept so
by the exertions of better men than himself." .... John Stuart Mill.
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Saturday, July 31, 2004 6:57 AM
> To: Jakarta Commons Developers List
> Subject: [io] Deprecate CopyUtils
>
>
> I have been looking at adding methods to IOUtils/CopyUtils,
> to handle additional types and to fix some holes.
>
> The net result is a realisation that the CopyUtils class was
> a poor creation (and it may even have been my idea!).
>
> - CopyUtils implements various methods that write byte[] and
> String to stream/writer but to this inefficiently via other
> writers/streams.
> - null handling is unclear.
> - the toXxx methods on IOUtils are strongly related to
> CopyUtils yet they are on a different class (they are the
> read() operations)
> - it is not logical to look on a 'copy' class to find a
> method when I just want to 'write' data (write a
> string/byte[] to file is not a copy operation in most peoples minds.)
>
> So, I propose the following:
> CopyUtils deprecated, methods moved to IOUtils.
>
> Write methods (string/byte[] to stream) are renamed to
> write(...) Copy methods (stream to stream) stay named as copy(...)
>
> The write methods will also change implementation to handle
> null string/byte[] and to be more efficient.
>
> The main downside is that it annoys users who are using
> CopyUtils. However, it does seem to be better to fix the
> issue and get the right API.
>
>
> Alternatives would include ReaderUtils, WriterUtils,
> InputStreamUtils, OutputStreamUtils, but then where do the
> actual copy methods go. Plus too much breaking up can be
> troublesome for users too. This strategy of IOUtils for low
> level streams/readers/writers and FileUtils for higher level
> files and FilenameUtils for even higher level seems to work
> well in my mind.
>
> If there are no objections I will commit these changes....
>
> Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org