On Thu, Feb 17, 2011 at 12:07 AM, Peter Niederwieser <[email protected]>wrote:
>
> I've been thinking about ways to improve Gradle's "configuration DSL" - the
> way domain objects (projects, tasks, etc.) get configured with closures.
> The
> current approach is similar to Groovy's Object.with {} method. It maps
> method/property calls inside the closure directly to method/property calls
> on the underlying object. What I like about this approach is that it is
> very
> simple and predictable. As soon as you know the API, you know the DSL. On
> the other hand, the approach also has some drawbacks:
>
> - Using the DSL doesn't give much over using the underlying object's API
> directly.
> - In order to provide a rich DSL, one has to inflate the API with
> getters/setters, methods accepting single arguments and/or varargs, methods
> with varying parameter types, etc.
> - As a result of inflating the API, code duplication and inconsistencies
> will creep in (property vs. method syntax, different coercions supported in
> different places, etc.). And the larger the API grows, the more difficult
> it
> will be to use directly, for example when implementing a plugin.
>
This is something we definitely need and want. We have been talking about
that for quiet a while. The consistency, particularly for file conversion,
would be very important.
>
> I'm proposing a "smarter" (excuse the word) configuration DSL. Such a DSL
> could allow this domain object:
>
> class Foo {
> String bar
>
> List<Integer> moos
>
> Map vars
>
> Dependency dep
> }
>
> ...to be configured as follows:
>
> foo {
> bar "some string"
>
> moo 5
> moo "6"
> moos 7, 8, 9
>
> vars one: 1, two: 2
>
> dep "junit:junit:4.8"
> dep new Dependency("junit", "junit", "4.8")
> }
>
> This example tries to give an idea of how:
> - a small and focused convention-based (bean-style) API could "generate" a
> rich DSL
> - a method-based DSL is less noisy and feels more declarative than a
> property-based DSL (no '=')
>
I was always not sure whether equals is good or bad. The equal makes it at
least clear whether you are adding or setting.
I guess 'moos 10' would add to [7,8,9]?
With moos = [11,12] you could replace the list.
> - a method-based DSL can leverage syntactic features such as varargs and
> named parameters
> - a smart DSL could accept arguments not accepted by the underlying API
>
> The last point is particularly important. The idea is that the DSL
> leverages
> a central service to automatically coerce arguments to the types expected
> by
> the API. This keeps the API small and guarantees that the same coercions
> are
> available everywhere, with zero effort on behalf of the API author. Plugins
> could potentially extend the set of known coercions.
>
> Of course the story doesn't end here. A smart configuration DSL could also:
> - allow arguments to be lazy by accepting a closure
> - free APIs from Groovy-specific types and conventions (for example by
> coercing closures to Gradle's Actions)
> - automatically issue a deprecation warning if a method marked with
> @Deprecated is called
> - etc.
>
> I've already implemented DSLs similar to the one outlined here with great
> success. The only clear downside that I can see is that taking Gradle into
> this direction would likely constitute a major breaking change. However,
> the
> potential benefits convinced me to bring up the topic anyway (and before
> 1.0). What do you think? Looking forward to hearing your opinions.
>
We should go ahead with that. First off all we don't need to remove the
setter/getter approach. That way we don't break anything in that respect.
Most of the time the current methods behave like the future implicit ones. I
don't think this will lead to many breaking changes.
Cheers
Hans
--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
>
> --
> Peter Niederwieser
> Developer, Gradle
> http://www.gradle.org
> Trainer & Consultant, Gradle Inc.
> http://www.gradle.biz
> Creator, Spock Framework
> http://spockframework.org
>
> --
> View this message in context:
> http://gradle.1045684.n5.nabble.com/Ideas-on-improving-Gradle-s-configuration-DSL-tp3388556p3388556.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
