Hi,
I'm working on a spec for implicit file value coercion. This will likely yield
some more general stuff for implicit type coercion, but the focus is for file
values. There are a few tricky problems.
In order to support “flexible input values” for files right now, you need to do
effectively this…
class MyTask extends DefaultTask {
Object someFile
File getSomeFile() {
someFile == null : null : project.file(someFile)
}
}
This allows (among other values) (1) …
task myTask(type: MyTask) {
someFile "path/to/file"
}
And (2):
task myTask(type: MyTask) {
someFile { someLazilyEvaluatedValue }
}
We want to avoid developers having to do this manually for a few reasons.
Developers should be able to just write the following and get the same
behaviour:
class MyTask extends DefaultTask {
File someFile
}
If we ignore #2 for the time being, we could do this by injecting a coercion
layer in the MOP. We would effectively intercept *every* method call, if it's a
coercible case then coerce the value and just call through to the declared
setter. That's actually quite a big change as it flips the relationship around
between the Groovy MOP and ours, but it's ultimately doable I think.
#2 provides lazy evaluation because the closure gets stored and evaluated on
demand by project.file() in the getter. If we decide that this story (implicit
file value coercion) means supporting this usage, then we are forced to answer
some uncomfortable questions about laziness and what we call convention
mapping.
Options:
1. Do not support deferring with this feature, all values are coerced
immediately.
2. Do support deferring, ultimately meaning on-demand coercion
I'm not sure how much of an option #1 actually is, given how widespread the use
of this feature is.
If we go with #2, what do we do about the crossover with convention mapping?
How much of that needs to be considered for this story? if we completely ignore
it and add another layer, we'd now have two different out-of-object places that
object data is stored. It starts to look like we should look at some
convergence here. If so, that raises the question of whether we can change any
convention mapping API without a deprecation cycle (if it turns out we need
to).
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
