On 28/07/2011, at 1:25 PM, Adam Murdoch wrote:
> On 28/07/2011, at 10:43 AM, Luke Daley wrote:
>
>> Hi guys,
>>
>> With the object containers, you cannot currently influence how an object is
>> to be created using the DSL eg.
>>
>> someContainer {
>> element1 {
>>
>> }
>>
>> element2 {
>>
>> }
>> }
>>
>> Where element1 and element2 are auto created via the existing mechanism. I'd
>> like to add support for the following…
>>
>> someContainer {
>> element1(foo: "bar") {
>>
>> }
>>
>> element2(baz: "bat") {
>>
>> }
>> }
>>
>> The idea being that implementations could use the attributes map to
>> influence how elements are auto created. I think that this is a good
>> capability generally, but it does make things slightly looser.
>
> I suspect something like this might be useful. For example, you'd be able to
> use it to define tasks:
>
> tasks {
> mytask(type: SomeType) { ... some config ... }
> }
>
> I would really like to move tasks into their own namespace, and this would
> allow us to do this.
>
> Building on this, we'd have a consistent DSL for containers of polymorphic
> elements, something like:
>
> repositories {
> someRepo(type: Ivy) { ... }
> someOtherRepo(type: Maven) { .... }
> }
“we'd have a consistent DSL for containers of polymorphic elements” - that's
the point I was trying to make.
>> For example, what would the default impl do? Would it ignore the properties?
>> Would it use them to configure the new element by map? Would it throw
>> UnsupportedOperationException.
>
> It would be nice if the factory declared which properties it needs
> (defaulting to an empty set), and any extra entries in the map are used to
> configure the new element by map. For example:
>
> tasks {
> myzip(type: Copy, from: sourceSets.main.output, into: 'someDir)
> // same as
> myzip(type: Copy) {
> from sourceSets.main.output
> into 'someDir'
> }
> }
>
> This approach deals nicely with the case where a property changes from
> required at construction time, to optional at construction time. Doesn't help
> with changes the other way, though.
Seems reasonable.
> Another question is what happens when you use the map approach when the named
> object already exists? Fail? Fail only if read-only properties specified in
> the map? Fail only if read-only properties specified in the map have
> different values to those on the target object?
>
>> The use case I have in mind is where a “native source set” has many outputs,
>> so something _like_:
>>
>> cpp {
>> sourceSets {
>> main {
>> // config of where source is
>> outputs {
>> main {
>> // configure how this is to be compiled
>> }
>> debug(parent: main) {
>> // add how to compile a debug variant, inheriting all of the main
>> settings
>
> A few comments on this del:
I wouldn't read too much into it, was just trying to come up with a practical
example.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
