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.
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. 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.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
