On 18/09/2012, at 1:50 AM, Adam Murdoch wrote:
>
> On 18/09/2012, at 8:13 AM, GitHub wrote:
>
>> Branch: refs/heads/master
>> Home: https://github.com/gradle/gradle
>> Commit: d0da246b7aecc632fc90c886d6a4b3421208c840
>>
>> https://github.com/gradle/gradle/commit/d0da246b7aecc632fc90c886d6a4b3421208c840
>> Author: Luke Daley <[email protected]>
>> Date: 2012-09-17 (Mon, 17 Sep 2012)
>>
>> Changed paths:
>> M
>> subprojects/core/src/main/groovy/org/gradle/api/internal/AsmBackedClassGenerator.java
>> A
>> subprojects/core/src/main/groovy/org/gradle/api/internal/ClosureBackedAction.java
>> A
>> subprojects/core/src/testFixtures/groovy/org/gradle/api/internal/ClosureBackedActionTest.groovy
>>
>> Log Message:
>> -----------
>> Extract ClosureBackedAction to a first level class and add some test
>> coverage.
>>
>>
>> Commit: 045e919a66198ebc4985b93fb6239df129ac6a89
>>
>> https://github.com/gradle/gradle/commit/045e919a66198ebc4985b93fb6239df129ac6a89
>> Author: Luke Daley <[email protected]>
>> Date: 2012-09-17 (Mon, 17 Sep 2012)
>>
>> Changed paths:
>> M subprojects/core/src/main/groovy/org/gradle/util/CollectionUtils.java
>> M
>> subprojects/core/src/test/groovy/org/gradle/util/CollectionUtilsTest.groovy
>>
>> Log Message:
>> -----------
>> collect for arrays
>>
>>
>> Commit: 1a284bda1bb810d09c860701e052f1e6684d799f
>>
>> https://github.com/gradle/gradle/commit/1a284bda1bb810d09c860701e052f1e6684d799f
>> Author: Luke Daley <[email protected]>
>> Date: 2012-09-17 (Mon, 17 Sep 2012)
>>
>> Changed paths:
>> A
>> subprojects/core/src/main/groovy/org/gradle/api/InvalidActionClosureException.java
>> M
>> subprojects/core/src/main/groovy/org/gradle/api/internal/ClosureBackedAction.java
>> M
>> subprojects/core/src/testFixtures/groovy/org/gradle/api/internal/ClosureBackedActionTest.groovy
>>
>> Log Message:
>> -----------
>> Added explicit error handling for using an invalid closure as an action
>> implementation.
>>
>>
>> Commit: 451cc4b8cdc694c8c717080f9b13df4a1b0c2e08
>>
>> https://github.com/gradle/gradle/commit/451cc4b8cdc694c8c717080f9b13df4a1b0c2e08
>> Author: Luke Daley <[email protected]>
>> Date: 2012-09-17 (Mon, 17 Sep 2012)
>>
>> Changed paths:
>> M
>> subprojects/core/src/main/groovy/org/gradle/api/internal/AbstractClassGenerator.java
>> M
>> subprojects/core/src/main/groovy/org/gradle/api/internal/AsmBackedClassGenerator.java
>> M subprojects/core/src/main/groovy/org/gradle/util/CollectionUtils.java
>> M
>> subprojects/core/src/test/groovy/org/gradle/api/internal/AsmBackedClassGeneratorGroovyTest.groovy
>>
>> Log Message:
>> -----------
>> Generate closure adapters for any method with an Action as the last
>> parameter.
>
> I'm wondering about our strategy for mixing in the DSL stuff, longer term.
>
> It feels like we should move this out of the class generation and into a
> DynamicObject implementation that the decorated class delegates to (which we
> already have). We don't actually need to mix this stuff in statically, and it
> might all be a bit simpler if we composed the DSL layer from a bunch of
> dynamic property and method handlers (we might bust up DynamicObject into a
> few separate facets to make this easier), instead of bloating out the class
> generation.
Pros:
1. Easier to write delegation code than ASM code
Cons:
1. Longer stack traces
2. Performance
3. Groovy specific solution
> Alternatively, if we do this statically, it would be nice if we could figure
> out a way to mix it in earlier in the development lifecycle so that it's
> available in, say, javadocs and code completion in the IDE and from static
> languages and so on.
We can make the DSL reference aware of this stuff. I think if we clearly
explain the rules somewhere then people can extrapolate from the raw javadocs.
For code completion in IDEA or Eclipse, this could be described using their DSL
descriptor stuff. Given that there's a runtime component though, I'm not sure
how well we could target the addition of the behaviour with the descriptors.
That is, I'm not sure how we'd identify in the descriptors what has been
decorated.
If this stuff was in the class files, it would mean we don't have to write the
DSL descriptors. We could do this at compile time I guess with a gradle
`gradle-plugin' plugin that decorates the class files. That throws up problems
with divergence from source and maybe throws up binary compatibility issues.
> Either way, we also need to have the DSL reference understand all the
> mixed-in stuff.
>
> While we're kind of on the topic, I'm curious if anyone has some suggestions
> for how a configuration DSL might be added for nested domain objects. So, say
> I have:
>
> class Thing {
> ThingOptions options = new ThingOptions()
> String name
> }
>
> I want methods to configure 'thing.options', but not 'thing.name', so that I
> can do things like:
>
> thing.options { option1 'foo' }
> thing.options(option1: 'foo')
>
> But I don't need to do things like:
>
> thing.name { // what would I do here? }
Why not just generate it for String as well? Agreed that it's of little use,
but what's the harm? If it makes the “rules” simpler and avoids need to
annotate what is configurable then it might be simpler to just do it for
everything.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
