On 10/02/2012, at 1:41 AM, Luke Daley wrote: > > 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.
I'd rather we did the stuff we planned to do, first. I don't really see this as a blocker for 1.0. Perhaps put it on the list and if we get to it, we get to it. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
