commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <>
Subject Re: [compress] New draft 5
Date Mon, 01 May 2006 00:38:15 GMT
On 4/30/06, will pugh <> 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
>, 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:
For additional commands, e-mail:

View raw message