groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: @AutoFinal(enabled=false) ?
Date Sun, 08 Oct 2017 23:16:19 GMT
My inclination would be that if you are going to have a disable option at
the method/constructor level, then I'd also enable it at the class level.
Imagine inheriting a large Groovy code base and you want to migrate it
towards have auto finals. With a class level option you could enable it
globally with a configscript and selectively disable on classes that you
haven't got around to "fixing" to comply with the stricter style yet. As
you start working on a class you might move it from the class level to just
the violating methods/constructors and then eventually remove all once you
have completed the conversion process. We have the same kind of approach in
place for CompileStatic.

Cheers, Paul.


On Mon, Oct 9, 2017 at 5:58 AM, MG <mgbiz@arscreat.com> wrote:

> Hi Groovy users,
>
> we are putting the final touches (no pun intended) on the Groovy
> @AutoFinal annotation. The intended use is to apply the annotation
> automatically to all project classes (see e.g.
> http://mrhaki.blogspot.co.at/2016/01/groovy-goodness-customi
> sing-groovy.html), thereby making all parameters anywhere in the project
> code final without the need to clutter the code with final keywords in
> parameter lists.
>
> The question is, if there should be support to disable the annotation
> selectively for e.g. a class or method. I personally think that disabling
> it for a class violates the principle of least surprise, but am not as sure
> for methods. So the question is, can anyone come up with a good example
> where disabling @AutoFinal selectively would make sense ?
> (Note: "So I can assign a value to a parameter" for me does not constitute
> such an example, since in that case one can just define a local, non-final
> variable and assign the parameter to it).
>
> Cheers,
> mg
>
>
>

Mime
View raw message