RE: [io] Deprecate CopyUtils

[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

RE: [io] Deprecate CopyUtils

[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