On 12/02/2012, at 4:32 AM, Luke Daley wrote:
>
>
>
>
> On 11/02/2012, at 3:46 PM, Szczepan Faber <[email protected]> wrote:
>
>> 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.
>
> My reasoning is that many plugin authors will target 1.0 as a baseline. If we
> introduce this later many won't use it until the baseline moves and it is
> there.
Given that we plan to add a heap of stuff to help plugin authors, I imagine the
baseline in practice will just end up being a few releases after 1.0 whether we
include this or not in 1.0.
>
>> 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.
>
> Most likely this will end up being baked into the DSL, you once we have that
> you'd just need to decorate the extension (via the instantiator).
>
> BTW, you should always use ConfigureUtil.configure() instead of manually
> fiddling with delegates.
>
>> 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.
>
> This is already better now that we have a public way of decorating
> extensions, but it's still not quite there.
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
