On Nov 4, 2008, at 12:32 AM, Adam Murdoch wrote:
Hans Dockter wrote:
Hi Adam,
I'm excited that we will get your transformer stuff into 0.5. I
have applied the transformers also to the SettingsConverter.
The name ModuleDescriptorContributor doesn't fit any longer. We
could go for something like: IvyObjectConfigurer. But I'm
wondering if it wouldn't be best to give it a truly general name
like: TransformableContributor
I wonder. The methods will need renaming to something general as well.
I think perhaps it's the pattern we should be reusing, if we come
across this problem again, rather than the interface.
Regardless, does this interface belong in the public API, or should
it remain in api.internal? So far, I've been avoiding adding direct
references to ivy classes to the public API, as I'm not sure its
the right thing to do. However, there are plenty of references
already there, so perhaps I should just add them in and worry about
the coupling later.
Probably. We don't have to care too much about API stability before
1.0. That doesn't mean we shouldn't pay attention but we can let it
evolve into one direction and later, based on experience, review this
approach and decide whether this is the right thing to do.
One other thing is the behavior of the addIvyTransformer(Closure
transformer) method. Right now the closure is executed and we pass
the transformable as an argument. In code this would look like:
addIvyTransformer { moduleDescriptor ->
moduleDescriptor.doThis()
moduleDescriptor.doThat()
}
What about passing no argument to the closure but setting the
delegate of the closure to the transformable (like we do it for
example in DefaultProject.allprojects)
addIvyTransformer {
doThis()
doThat()
}
This is definitely an option. The problem is that some of the ivy
classes we use are immutable, such as Configuration.
We've been through this but I had forgotten again.
Perhaps we could do both: pass the transformable object in as a
parameter, and set it as the delegate. If the closure returns an
object of the same type as the transformable, we use it as the
result. Otherwise we use the passed in object as the result.
This is an excellent idea.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
