On 04.10.2016 16:32, Graeme Rocher wrote:
[...]
I would like to propose adding the ability to create builders that can
be statically compiled by adding a capability similar to Scala's
Dynamic:
https://issues.apache.org/jira/browse/GROOVY-7957
the question is what you really gain from that... let us assume it is
enough to annotate a class with @SDyn to make every use of it like you
describe:
@SDyn
class Foo {
String bar(int i) {"i"}
def methodMissing(String s, Object args){ null }
}
@CompileStatic
def test() {
def foo = new Foo()
String s1 = foo.bar(1) // (1)
String s2 = foo.foo() // (2)
def s3 = foo.bar("") // (3)
}
(1), here we get the compile time checks for the existance of a method
bar(int) as well as that the declared type of s1 and the return type of
bar fit together
(2) would compile against using methodMissing, but the result will be
Object, so this will fail compilation
(3) would compile using methodMissing, since bar(String) is not
bar(int). This behaviour is in line with the dynamic methodMissing
behavior, but not with the one from Scala.
In other words, for static compilation you will not get any useful
return types, you will not really get a faster builder and you will not
gain protection against typos. I don't even see auto-completion in IDEs
as pro argument here, since @DelegatesTo is in theory enough for that
already. And if you start nesting in your builder you will have to write
methods for it, otherwise you have no place for a @DelegatesTo.
So I guess the goal of this feature needs a bit more discussion.
bye Jochen
