@AutoFinal(enabled=false) ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
MG
Reply | Threaded
Open this post in threaded view
|

@AutoFinal(enabled=false) ?

MG
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-customising-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


Reply | Threaded
Open this post in threaded view
|

Re: @AutoFinal(enabled=false) ?

paulk_asert
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 <[hidden email]> 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-customising-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



MG
Reply | Threaded
Open this post in threaded view
|

Re: @AutoFinal(enabled=false) ?

MG
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 <[hidden email]> 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-customising-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




Reply | Threaded
Open this post in threaded view
|

Re: @AutoFinal(enabled=false) ?

paulk_asert
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 <[hidden email]> 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 <[hidden email]> 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-customising-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





MG
Reply | Threaded
Open this post in threaded view
|

Re: @AutoFinal(enabled=false) ?

MG
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.

Cheers,
Markus


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 <[hidden email]> 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 <[hidden email]> 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-customising-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