I think we should do this for 1.0.
If we provide a public API for this and start encouraging people to use it,
then all the plugins will get all of our DSL improvements for free going
forward. I think this is better than waiting for our DSL magic to get better
and then having 3rd party code start leveraging it.
It's going to take a lot of magic to completely hide this (i.e. making new
DomainObject() return a decorated object) and I'm not entirely convinced that's
desirable. While you can overload constructors in Groovy I don't think it's a
good practice. It also doesn't help you for Java code.
One pro of the constructor overload approach is that IDEs can help you complete
the construction call. I don't think that's enough to warrant it though.
For my mind, this level of indirection (i.e. having to use
instantiator.newInstance(Foo, "bar")) is an acceptable burden to put on plugin
developers.
…
I just thought of a complication.
It seems feasible that the DSL will one day handle coercion of Object → File.
This may mean we'll need to tie the instantiator to a Project so it knows the
base. However, it's conceivable to want to do this…
class Foo {
File bar
}
project.gradle.extensions.add("foo" , Foo)
gradle {
foo {
bar "someDir"
}
}
The point being that instantiation may require some kind of context for the DSL
magic.
We could probably hide this though and have the instantiator returned by
different objects inject its context into the object it creates.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
