groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Proposal: Statically compileable builders
Date Tue, 04 Oct 2016 15:43:27 GMT


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



Mime
View raw message