[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-09-12 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16162547#comment-16162547
 ] 

ASF GitHub Bot commented on GROOVY-8300:


Github user asfgit closed the pull request at:

https://github.com/apache/groovy/pull/594


> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>Assignee: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Discussion points:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise? 
> *Current thinking*: it should apply to all methods. We can always introduce 
> an additional annotation attribute at a later point if there is demand.
> # Should there be support for 'includes' or 'excludes' functionality? 
> *Current thinking*: don't support this for now. The annotation can be applied 
> on multiple methods/constructors if finer granularity than the class level is 
> required.
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties? 
> *Current thinking*: don't support this for now. An annotation attribute could 
> be added later if we wanted to optionally turn such extra cases on.
> # Should it apply to synthetic methods/constructors added by the 
> compiler/other transforms? *Current thinking*: Don't apply to synthetic 
> methods unless we find special cases were it is needed.
> # What phase should this run at? It needs to be before the (incubating) final 
> variable analyser is run. *Current thinking*: SEMANTIC_ANALYSIS
> # We should have tests to confirm that there are no adverse interactions with 
> other language features, e.g. default parameter values. *Note*: we should 
> have a test case that covers this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-30 Thread mg (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16147558#comment-16147558
 ] 

mg commented on GROOVY-8300:


Hi Paul,
while programming at work, I thought of something we might have overlooked: Are 
we handling closure arguments right now ?-)
Closures become classes afaik, so we would get them if 1) the closure class' 
methods already exist in the AST at this point, and 2) they are not 
"synthetic"...
Cheers,Markus


> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>Assignee: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Discussion points:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise? 
> *Current thinking*: it should apply to all methods. We can always introduce 
> an additional annotation attribute at a later point if there is demand.
> # Should there be support for 'includes' or 'excludes' functionality? 
> *Current thinking*: don't support this for now. The annotation can be applied 
> on multiple methods/constructors if finer granularity than the class level is 
> required.
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties? 
> *Current thinking*: don't support this for now. An annotation attribute could 
> be added later if we wanted to optionally turn such extra cases on.
> # Should it apply to synthetic methods/constructors added by the 
> compiler/other transforms? *Current thinking*: Don't apply to synthetic 
> methods unless we find special cases were it is needed.
> # What phase should this run at? It needs to be before the (incubating) final 
> variable analyser is run. *Current thinking*: SEMANTIC_ANALYSIS
> # We should have tests to confirm that there are no adverse interactions with 
> other language features, e.g. default parameter values. *Note*: we should 
> have a test case that covers this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-28 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144617#comment-16144617
 ] 

ASF GitHub Bot commented on GROOVY-8300:


GitHub user paulk-asert opened a pull request:

https://github.com/apache/groovy/pull/594

GROOVY-8300: Initial version sans tests and having no configuration o…

…ptions

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paulk-asert/groovy groovy8300

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/594.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #594


commit fe2e3abcd038d64072bb60929946009012575761
Author: paulk 
Date:   2017-08-29T00:57:53Z

GROOVY-8300: Initial version sans tests and having no configuration options




> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Discussion points:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise? 
> *Current thinking*: it should apply to all methods. We can always introduce 
> an additional annotation attribute at a later point if there is demand.
> # Should there be support for 'includes' or 'excludes' functionality? 
> *Current thinking*: don't support this for now. The annotation can be applied 
> on multiple methods/constructors if finer granularity than the class level is 
> required.
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties? 
> *Current thinking*: don't support this for now. An annotation attribute could 
> be added later if we wanted to optionally turn such extra cases on.
> # Should it apply to synthetic methods/constructors added by the 
> compiler/other transforms?
> # What phase should this run at? It needs to be before the (incubating) final 
> variable analyser is run.
> # We should have tests to confirm that there are no adverse interactions with 
> other language features, e.g. default parameter values.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-28 Thread mg (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144530#comment-16144530
 ] 

mg commented on GROOVY-8300:


@What phase should this run at: As early as possible ?

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Discussion points:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise? 
> *Current thinking*: it should apply to all methods. We can always introduce 
> an additional annotation attribute at a later point if there is demand.
> # Should there be support for 'includes' or 'excludes' functionality? 
> *Current thinking*: don't support this for now. The annotation can be applied 
> on multiple methods/constructors if finer granularity than the class level is 
> required.
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties? 
> *Current thinking*: don't support this for now. An annotation attribute could 
> be added later if we wanted to optionally turn such extra cases on.
> # Should it apply to synthetic methods/constructors added by the 
> compiler/other transforms?
> # What phase should this run at? It needs to be before the (incubating) final 
> variable analyser is run.
> # We should have tests to confirm that there are no adverse interactions with 
> other language features, e.g. default parameter values.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-28 Thread mg (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144525#comment-16144525
 ] 

mg commented on GROOVY-8300:


@synthetic methods/constructors: 
# Can we be sure that the synthetic code does not want to modify its parameters 
?
# Shouldn't the implementer of the synthetic code generator decide whether to 
use final or not ?
# I think it is not worth the risk of introducing incompatibilities between 
(future) synthetic code parts and @AutoFinal

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Discussion points:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise? 
> *Current thinking*: it should apply to all methods. We can always introduce 
> an additional annotation attribute at a later point if there is demand.
> # Should there be support for 'includes' or 'excludes' functionality? 
> *Current thinking*: don't support this for now. The annotation can be applied 
> on multiple methods/constructors if finer granularity than the class level is 
> required.
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties? 
> *Current thinking*: don't support this for now. An annotation attribute could 
> be added later if we wanted to optionally turn such extra cases on.
> # Should it apply to synthetic methods/constructors added by the 
> compiler/other transforms?
> # What phase should this run at? It needs to be before the (incubating) final 
> variable analyser is run.
> # We should have tests to confirm that there are no adverse interactions with 
> other language features, e.g. default parameter values.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-28 Thread mg (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144312#comment-16144312
 ] 

mg commented on GROOVY-8300:


I see your side. As as you said, we probably will never have the first two 
options (includeFields/includeProperties), and right now I also cannot see the 
3rd and 4th  (includeMethods/includeConstructors). But this is the way other 
Groovy annotations have been done - and the 
includeMethodParams/includeConstructorParams parameters also should make it 
clear that this annotation currently refers only to parameters.


> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Discussion points:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise? 
> *Current thinking*: it should apply to all methods. We can always introduce 
> an additional annotation attribute at a later point if there is demand.
> # Should there be support for 'includes' or 'excludes' functionality? 
> *Current thinking*: don't support this for now. The annotation can be applied 
> on multiple methods/constructors if finer granularity than the class level is 
> required.
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties? 
> *Current thinking*: don't support this for now. An annotation attribute could 
> be added later if we wanted to optionally turn such extra cases on.
> # Should it apply to synthetic methods/constructors added by the 
> compiler/other transforms?
> # What phase should this run at? It needs to be before the (incubating) final 
> variable analyser is run.
> # We should have tests to confirm that there are no adverse interactions with 
> other language features, e.g. default parameter values.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-28 Thread Paul King (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143608#comment-16143608
 ] 

Paul King commented on GROOVY-8300:
---

I suspect we won't ever introduce that ability to apply to fields but if we did 
it might be something like {{@AutoFinal(includeFields=true)}} rather than 
{{@AutoFinalFields}}.

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Discussion points:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise? 
> *Current thinking*: it should apply to all methods. We can always introduce 
> an additional annotation attribute at a later point if there is demand.
> # Should there be support for 'includes' or 'excludes' functionality? 
> *Current thinking*: don't support this for now. The annotation can be applied 
> on multiple methods/constructors if finer granularity than the class level is 
> required.
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties? 
> *Current thinking*: don't support this for now. An annotation attribute could 
> be added later if we wanted to optionally turn such extra cases on.
> # Should it apply to synthetic methods/constructors added by the 
> compiler/other transforms?
> # What phase should this run at? It needs to be before the (incubating) final 
> variable analyser is run.
> # We should have tests to confirm that there are no adverse interactions with 
> other language features, e.g. default parameter values.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-28 Thread mg (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143515#comment-16143515
 ] 

mg commented on GROOVY-8300:


I would strongely argue to change the name to e.g. @AutoFinalParams because of 
# least surprise: Reading @AutoFinal I would assume it applies to fields etc too
# Applying this annotation to specific classes only would imho be confusing; 
but if it is applied to the whole project, the length of the annotation name 
should not matter
# Potentially adding e.g. @AutoFinalFields in the future would make @AutoFinal 
even more confusing

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Discussion points:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise? 
> *Current thinking*: it should apply to all methods. We can always introduce 
> an additional annotation attribute at a later point if there is demand.
> # Should there be support for 'includes' or 'excludes' functionality? 
> *Current thinking*: don't support this for now. The annotation can be applied 
> on multiple methods/constructors if finer granularity than the class level is 
> required.
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties? 
> *Current thinking*: don't support this for now. An annotation attribute could 
> be added later if we wanted to optionally turn such extra cases on.
> # Should it apply to synthetic methods/constructors added by the 
> compiler/other transforms?
> # What phase should this run at? It needs to be before the (incubating) final 
> variable analyser is run.
> # We should have tests to confirm that there are no adverse interactions with 
> other language features, e.g. default parameter values.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread Paul King (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143369#comment-16143369
 ] 

Paul King commented on GROOVY-8300:
---

I tend to agree with your comments. I'll update the description.

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Still to be determined:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise?
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread mg (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143178#comment-16143178
 ] 

mg commented on GROOVY-8300:


As a side note: A similar result to @AutoFinalParams could also be achieved 
through IDE support, if the IDE could optionally hide the final keywords, and 
replace them e.g. through displaying final parameters in a different color. 
However 
# To my knowledge no such support currently exists e.g. in IntelliJ
# One is not always in an IDE environment (e.g. script development, application 
DSL)
# IDE support along the same line could also help making application of 
@AutoFinalParams more explicit

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Still to be determined:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise?
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread mg (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143170#comment-16143170
 ] 

mg commented on GROOVY-8300:


I think method visibility does not need to be taken into consideration because:
# Imho either one wants to be sure parameters cannot be changed by accident - 
or not, and I do not see how this could depend on whether a method is e.g. 
private or public
# But more importantly: I feel auto applying the final keyword to parameters 
under certain circumstances only would be confusing in practice, so I would 
argue against it.

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Still to be determined:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise?
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread mg (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143168#comment-16143168
 ] 

mg commented on GROOVY-8300:


If e.g. a team decides all fields/properties shall be final by design (forcing 
(one-time-only) initialization by ctor only), I could see potential use for 
also having an "auto final" option for fields/properties. However since 
field/property declarations are typically given as one-per-line, reduction of 
clutter is less of an issue here. Also one might want to have a non-final field 
for debugging purposes, etc, so overall I do not see this as nearly as useful a 
feature in practice.

I would therefore suggest that this annotation should only apply to method 
parameters, and should accordingly be renamed @AutoFinalParams.


> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Still to be determined:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise?
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)