On 09/02/2012, at 2:10 PM, [email protected] wrote:
> If FileOperations is going to be made public as is, I would suggest that
> FileResolver be made public at the same time. The public API shouldn't have
> methods whose return type is an internal interface.
A quick look suggests that it might be best to make FileOperations public, and
change some of our to use FileOperations instead of FileResolver as a gradual
change as we promote more to the public space.
I'm thinking of things like DefaultSourceDirectorySet which should become
public before too long.
> The main (and I think only) thing I use FileResolver for is the withBaseDir
> method. Maybe adding a file(Object parent, Object name) method would remove
> that need for me.
What would this do that's different to project.file("$parent/$name") ?
Rather than add this method, it might be better to be able to derive
FileOperations instances with different bases. So adding…
FileOperations fileOperationsWithBaseDir(Object base)
Then your above would be something like:
project.fileOperationsWithBaseDir(parent).file(name)
If we can manage I think we should go to 1.0 with public api for our Object →
File logic.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
