The default named-argument constructors should work with final fields

[GoogleCodeExporter]

class Foo { 
  final int foo
  final int bar 
}

new Foo(foo:2, bar:3)

Compilation fails. I think it shouldn't

Original issue reported on code.google.com by gromop...@gmail.com on 6 Mar 2011 at 11:44

[GoogleCodeExporter]

It's core groovy level restriction, because it handles "new Foo(foo:2, bar:3)" 
like:

x = new Foo()
x.setProperty(foo,2)
x.setProperty(bar,3)

Original comment by roshanda...@gmail.com on 6 Mar 2011 at 2:44

[GoogleCodeExporter]

Roshan, does this imply that such thing wouldn't be nice to have?

Original comment by gromop...@gmail.com on 6 Mar 2011 at 5:58

[GoogleCodeExporter]

I like the way your example reads, but which constructor will it push the 
properties through? If you use no-arg constructor, then you will be setting the 
final properties after the instance is created. If not no-arg constructor, then 
Groovy cannot so freely add a constructor that takes a map of properties.

You see a way out?

Original comment by roshanda...@gmail.com on 6 Mar 2011 at 6:05

[GoogleCodeExporter]

Why can't it? I don't see any problems creating such a private constructor with 
a factory method. The map creation is unnecessary, just pass the arguments in a 
correct order.

Original comment by gromop...@gmail.com on 6 Mar 2011 at 6:11