On 23.05.2016 10:59, Thibault Kruse wrote:
Cedric's comment linked at the bottom of that post is excellent in
describing the issue. The gradle DSL has been designed in a way that is
hard to support by IDEs, partly because groovy made that so easy.
And the same might be true about other popular groovy frameworks. Having
to support plugins for each IDE for each framework specific DSL is not
viable.
If there were a lesson to be learned here for a vastly different groovy
3, it is hard to imagine that in practice those lessons could be applied.
The lesson would be to have static typed DSLs, and if you want to be
language implementation agnostic, you need the description in something
anyone can read. So the maximum that is allowed is annotations of some
kind - or a DSL to describe the DSL.
The later exists, is called GDSL, and even though IDE specific, it is
not very well supported by the same IDEs.
And what we have in first possibility might be on par with many other
DSL supporting languages, but not working out well enough for Gradle.
That is, if you want to keep the DSL as is.
I am wondering more about something like this:
http://mrhaki.blogspot.de/2013/05/gradle-goodness-extending-dsl.html
So if that basically means adding new DSL parts to any arbitrary (but
ExtensionAware) element in the build system. Then you need to define a
way to connect that in a static way for a static view to be able to do
static checks. I guess that would be extension functions then.. The
difference between their extension functions and our extension methods
is, that theirs is potentially more easy to use, since you do not need
to produce a descriptor. There was never really a need for that so far
in Groovy, but it certainly could be implemented. The static compiler
already understands extension methods, so it would be just a matter of a
different descriptor of some kind, plus making that available at compile
time.
I really would like to see a gradle DSL example in Kotlin that cannot
made static checked in Groovy. Because things like accessing dynamic
properties won´t work in Kotlin as well.
If they really wanted to there would be a way.
bye Jochen
