groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: traits fields initialization order ?
Date Sat, 10 Mar 2018 21:10:21 GMT
There is a known bug in trait initialization for final fields:

https://issues.apache.org/jira/browse/GROOVY-8281

It's on my list to fix before 2.5.0 final. Happy for any assistance.

Cheers, Paul.


On Sun, Mar 11, 2018 at 6:37 AM, MG <mgbiz@arscreat.com> wrote:

> Hi,
>
> I recently refactored the reflection code of my framework to support using
> traits to share fields. The shared fields are initialized during field
> declaration (i.e. not in a ctor) for user convenience (they represent
> columns in a table). In this particular case, fields needed to be passed as
> parameters to to other field's ctors. In this case the problem is, that the
> fields passed to other fields ctors seem to alwys be null. The same code
> constructs have been working for years when using them directly inside a
> class.
>
> Questions:
>
>    1.  What is the expected behavior in this case ? Should this work in
>    traits ?
>    2. If this is not a bug in Groovy: What is the best workaround ? I
>    only had very little time to work on this last week, so I used a @Memoized
>    helper method whose return value is used in both the field initializations
>    - works, but a pretty terrible solution and user experience.
>    I just did a quick spike at home using @Lazy on one field: This seems
>    to work, but not, if combined with final - so the field could be reassigned
>    (which I don't want) unless the framework user introduces a shared @Lazy
>    "hidden" private helper field (similar to my @Memoized method).
>    3. In general: What is the exact order that fields get initialized in
>    Groovy - and is this behavior expected to change in the future ?
>
> Cheers,
> mg
>
>
>
>

Mime
View raw message