Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41FE1649.1010005@alumni.rice.edu>
Date: Mon, 31 Jan 2005 05:28:09 -0600
From: "B. K. Oxley (binkley)" <binkley@alumni.rice.edu>
Organization: The Oxley Family
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [vfs] proposal: FileUtils
References: <41F17027.30402@alumni.rice.edu> <41F17CF5.4060803@ops.co.at>
 <41F18708.1070709@alumni.rice.edu> <41FD61C6.9000706@alumni.rice.edu>
 <41FDDE5F.1070203@ops.co.at>
In-Reply-To: <41FDDE5F.1070203@ops.co.at>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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
FileSystemException;
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
operations.save(src, otherFile.getInputStream());
operations.save(src, 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.  :-)


Cheers,
--binkley

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org