Re: Putting Generated on private Trait methods
Paul King <[email protected]> Wed, 29 Oct 2025 15:06:49 +1000
| Newsgroups | gmane.comp.lang.groovy.user |
|---|---|
| Message-ID | <CAMbkE7TKh1fXYLFfpUYR4QYiPSUX5H9x4XEF9yF2qFAh9OL+3A@mail.gmail.com> |
I am not sure if it is needed in that particular case. I know there was a time when requests were made in similar cases to please coverage tools. Sometimes the generated methods can be more difficult to get full test coverage for, so some tools just ignore any generated methods when calculating coverage percentages. A purest could argue that you'd want full coverage of those methods also, but at the time we were shown enough cases that convinced us it was worth adding. I don't know if Grails would be impacted by the same problem, but it gives some background as to why it may have been done. Cheers, Paul. On Wed, Oct 29, 2025 at 12:27=E2=80=AFAM Mattias Reichel <[email protected]= > wrote: > > We have recently merged a PR[1] in Grails that adds the > groovy.transform.Generated annotation to all Trait methods so that > they do not screw up test coverage statistics when they are added to > implementing classes. > > I noticed that the PR also added the annotation to private methods in > the Traits and I am curious if this is necessary? > > According to AI: > > A private method in a Groovy Trait is trait-private: it=E2=80=99s compi= led into the trait=E2=80=99s helper class and used only by other methods in= the trait. It is not added to (or visible on) the implementing class, so y= ou can=E2=80=99t call it from the class (or from other traits). > > > A trait-private method is already an internal implementation detail and= won=E2=80=99t be added to or visible on implementing classes. Annotating i= t with @Generated doesn=E2=80=99t change semantics or visibility. > > Thanks for any wisdom on this! > /Mattias > > [1] https://github.com/apache/grails-core/pull/15150