On 15/02/2012, at 10:47 PM, Ken Sipe wrote:
> It might be worth restating the problem... to my understanding there is an
> issue with mostly people new to groovy not discovering (or taking too long to
> discover) that they mistyped a property and instead of assigning a value to
> an existing property they are creating a new property and assigning value to
> it. It would help to understand if there is something more than this…
That's the crux of it. Allowing creation on demand has proven to be too
dangerous for the reasons you cite.
That's what absolutely has to be fixed, and the rest is about longer term
benefits of different strategies.
> IMO the approach you suggest seems to move too much in the direction of a
> Java idiom... my preference would be to maintain a groovy idiom. realizing
> that your suggested approach would work just fine in a groovy world...
>
> When I think about a solution my mind gravitates toward the ExpandoMetaClass
> or the groovy mocking demand object. In this approach it feels groovy like,
> yet is very explicit.
>
> so if we assume we have an ext object available for all gradle objects or
> some subset... which of course would make the property ext reserved. then
> the solutions you provided below would look like:
>
> project.ext.foo = "bar" or
> project.ext['foo'] = "bar
>
> assert project.foo == "bar"
>
> Is there something I'm missing? or other reasons this wouldn't make sense?
It's just shifting the problem. Say a release engineer has plugin that does
this…
project.extensions.addDynamic("releaseInfo") {
flavour = null
}
Then a user does this…
project.releaseInfo {
flavor = "enterprise"
}
We've got the exact same problem, that's just as hard to debug. If you
absolutely want full dynamism, you could do this…
project.extensions.add("releaseInfo", [flavour: null])
But I don't think we want to encourage this out of the box. We want to provide
a way to have ad hoc storage without hanging yourself.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
