commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B. K. Oxley (binkley)" <>
Subject Re: [vfs] proposal: FileUtils
Date Mon, 31 Jan 2005 11:28:09 GMT
Mario Ivankovits wrote:
> Where do you think to implement this FileOperation interface? I miss
>  the "source" fileobject -a s I said, I dont want to implement the 
> interface in the FileObject and thus thought about something like 
> this:
> DefaultFileOperations.get().copy(FileObject src, FileObject dest);

I was going to pass the src in on construction of the operation object,
but why?  Using src as part of the parameter list seems just as good.

> void save(final OutputStream newContents, final FileObject dest, 
> final boolean overwrite) throws FileSystemException;

I have a strong distaste for using flags to control behavior in public
methods.  I find that it often leads to bugs when the flags are wrong,
and it makes understanding the code more difficult.  That is why I
prefer explicitly named methods:

void save(final OutputStream newContents, final FileObject dest) throws
void saveAndOverwrite(final OutputStream newContents, final FileObject
dest) throws FileSystemException;

How strong is your preference?

> If overwrite=false and the destination exists the methods should use 
> "backup()" to create a backup of the destination file

As an alternative, I took someone's suggestion of a policy object when I
started coding a default implementation of the FileOperation interface,
and let the policy object figure these things out.

> Another thing we could discuss is the usage of save(InputStream,
> ...). I renamed it to copy(InputStream, ...). I think if you do have
> an InputStream you would like to copy its output to another file - in
> opposite to save(OutputStream ...) where you do have the content of
> the file in memory (a bufferedImage, ....) and would like to "save"
> it.

I like save() because it describes the operation most closely from the 
point of view of the caller ("Hey, save this file with these new 
contents!").  The reason I used InputStream everywhere was for 
genericness (is that a word?).  I pictured usage like this:

// copy(src, dst) in your snippet, otherFile.getInputStream());, new ByteArrayInputStream(blobInMemory.toArray());

This sort of "negotiation" over interface is painful remotely.  I'd 
rather do it with my programming pairmate while writing unit tests.  :-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message