groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: @AutoFinal(enabled=false) ?
Date Mon, 09 Oct 2017 22:15:59 GMT
OK, if you already have implemented the feature than any further 
discussion is moot. People who want to prohibit devs in a project to 
disable @AutoFinal selectively on e.g. a class will have to employ a 
CodeNarc rule, and that is that.


On 09.10.2017 03:53, Paul King wrote:
> I added the ability to disable. It is similar to what we do in other 
> places and just because the flag is there, doesn't mean you have to 
> use it. Anyway, have a play and let me know what you think.
> Cheers, Paul.
> On Mon, Oct 9, 2017 at 10:42 AM, MG < 
> <>> wrote:
>     Hi Paul,
>     a temporal refactoring argument - good point.
>     But you could also temporarily enable AutoFinal for a project and
>     start fixing the spots which do not compile, and only when you are
>     finished (I would actually expect this to take much less time than
>     switiching a project to CompileStatic, since the fixes are much
>     more trivial), permanently turn on AutoFinal for the whole
>     project. I think my argument still applies here: AutoFinal is
>     useful, when you can trust that it is active everywhere. If you
>     are not worried about that, there is no need for you to use final
>     anywhere (be it automatic or explicit) in the first place. That is
>     why I suggested a compiler switch in the beginning (though I get
>     and accept why that was rejected).
>     "Doing things the same as in other parts of Groovy" is of course
>     an argument that generally does make sense. "Least surprise" with
>     regard to interfaces... ;-)
>     KR,
>     Markus
>     On 09.10.2017 01:16, Paul King wrote:
>>     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 <
>>     <>> 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.
>>         <>),
>>         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

View raw message