traits fields initialization order ?

[MG <mg...@arscreat.com>]

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

Re: traits fields initialization order ?

[MG <mg...@arscreat.com>]

Hi Paul,

thank you for the feedback (I searched the Groovy Jira, but was using 
"field assignment" as the search term, so missed this issue).
Weird bug, just taking away all the final qualifiers actually works, no 
@Lazy required - I didn't even test that far, since that is such a 
general problem, that I would have thought people would already have 
complained about this in troves...

Cheers,
mg


On 10.03.2018 22:10, Paul King wrote:
> 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 
> <ma...@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
>
>
>
>

Re: traits fields initialization order ?

[Paul King <pa...@asert.com.au>]

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 <mg...@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
>
>
>
>