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

Paul King closed GROOVY-8300.
-----------------------------

> 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
>            Priority: Major
>             Fix For: 2.5.0-beta-2
>
>
> 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
(v7.6.3#76005)

Reply via email to