commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [io] Deprecate CopyUtils
Date Mon, 09 Aug 2004 21:20:09 GMT
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" <dev.jeremias@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


Mime
View raw message