[
https://issues.apache.org/jira/browse/GROOVY-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748767#comment-17748767
]
Eric Milles commented on GROOVY-10801:
--------------------------------------
I am thinking about moving StaticImportVisitor to the start of instruction
selection. Is there a specific reason it is at the start of semantic analysis?
If all the transforms that generate members can run, then static imports can
be resolved much more accurately.
> AST transform for simple utility classes (only static fields and methods)
> -------------------------------------------------------------------------
>
> Key: GROOVY-10801
> URL: https://issues.apache.org/jira/browse/GROOVY-10801
> Project: Groovy
> Issue Type: New Feature
> Components: ast builder
> Reporter: Eric Milles
> Assignee: Eric Milles
> Priority: Minor
>
> Similar to the {{@Category}} transform, I'd like to have a local transform
> for utility classes. Consider the following:
> {code:groovy}
> @Namespace
> class C {
> int constant = 1
> def method() {
> // ...
> }
> }
> {code}
> This would be Groovy shorthand for the canonical "utility class":
> {code:groovy}
> final class C {
> private C() { throw new AssertionError() }
> public static final int constant = 1
> static method {
> // ...
> }
> }
> {code}
> *Update:* Like {{trait}} or {{record}}, we might consider taking this to the
> next step:
> {code:groovy}
> namespace C {
> int constant = 1
> def method() {
> // ...
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
