commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@apache.org>
Subject Re: [compress] New draft 5
Date Mon, 01 May 2006 00:38:15 GMT
On 4/30/06, will pugh <willpugh@sourcelabs.com> wrote:
> 1)  You often change method names based on the parameter types, e.g.
> Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
> setUnpackDestinationFile, etc.  It seems more conventional  and less
> chaotic to give all the methods the same name, and have them only differ
> based on parameter.  Examples of this style are constructors for
> java.utils.zip.ZipFile, java.io.FileInputStream,
> java.io.FileOutputStream, org.apache.commons.io.IOUtils.IOUtils.copy,
> org.apache.commons.io.FileUtils.isFileNewer, etc

This is intentional, in a previous version the method names were the
same. The problem with using the same name but different param types
breaks the JavaBean property getter/setter rules and the classes will
not be as usable in at least some scripting environments.

> 4)  None of your interfaces deal with the case of what to do if the
> destination file is already there.  Choices are either defining it in
> the interface, or adding a property defining what to do.  I would
> suggest the latter, and would suggest that for Archiver this method
> should take a FileFilter (since the unpack behaviour can be non-trivial)
> and should default to FalseFileFilter.INSTANCE.  For the Compresser
> interface a simple boolean is probably sufficient.  e.g.
>
>     Archiver.setOverwriteFilter(TrueFileFilter.INSTANCE)
>     Compresser.setOverwrite(true);

I'll disagree that this should be configurable. IMO it should just do
whatever FileOutputStream or whatever is used does. It's the calling
code's responsibility to handle any name collisions.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

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