It doesn't feel like a blocker for 1.0
It is important feature no doubt and if it makes it in 1.0 I'd be very
happy, though.
Here's the use case I'm most interested in. Say my extension is something
more robust than mere few properties, I need something like:
myExt {
myProp = 123
myPropSet {
user = 'foo'
dir = 'xxx'
}
}
With the current extension mechanism is kinda hard to implement myPropSet,
e.g. I need create an explicit myPropSet method, configure the
DELEGATE_FIRST, etc.
I remember Tim's session on plugins at PAX'11, he was using 'convention'
mechanism. After the session we've tried to reimplement his demo using
extensions but it wasn't slick.
Cheers
On Thu, Feb 9, 2012 at 3:58 PM, Luke Daley <[email protected]>wrote:
> 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
>
>
>
--
Szczepan Faber
Principal engineer@gradleware
Lead@mockito
