On 14/04/10 6:29 PM, Steven Devijver wrote:
Hey,
I've noticed that modifying the list returned by Test#getJvmArgs() has
no effect:
test.configure {
jvmArgs << "-Xdebug"
jvmArgs
<< "-Xrunjdwp:transport=dt_socket,address=11111,server=y,suspend=y"
}
Instead I have to do:
test.configure {
def args = []
args << "-Xdebug"
args
<< "-Xrunjdwp:transport=dt_socket,address=11111,server=y,suspend=y"
jvmArgs(args)
You could simplify this to:
test {
jvmArgs '-Xdebug', '-Xrun...'
}
}
Is this as intended?
It is, for this particular case. However, we don't really have a
consistent approach to the mutability of collection properties. Some you
can mutate, some you can't.
I wonder what our policy should be. Our general pattern for a
multi-valued property is to have the following methods:
SomeCollectionType<SomeType> getSomeProperty()
void setSomeProperty(Iterable<? extends SomeType> values)
void someProperty(SomeType... values)
this lets you do:
someProperty = ['a', 'b', 'c'] // sets the value, replacing existing value
someProperty 'a', 'b', 'c' // adds to the collection
We generally assume that you don't mutate the property value directly.
The question is, should we also allow the following sorts of expressions
for mutating a collection:
someProperty << 'a'
someProperty += ['a', 'b', 'c']
someProperty.clear()
From a user's point of view, the answer would be yes. From a Gradle
developer's point of view, the answer is, please no.
The problem is that generally, the implementation needs to react to
changes in the collection, for example, to do validation, update
internal structures, and so on. With just a setter and an adder method
to consider, the implementation can be pretty simple. When the
collection can be directly mutated as well, then the number of ways
things can change grows substantially. And the implementation cost goes up.
So, I'd rather say that, for now, collections should not be mutated
directly, and that, at some point before 1.0, we add a general mechanism
in Gradle that lets us easily and consistently allow collections to be
mutated. We need something which helps us keep the DSL consistent across
the entire API, so that we can change the rules for the DSL (eg
collection properties should be directly mutatable) and have the rule be
automatically applied across the entire API (and ideally, 3rd party
plugin APIs, too).
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
