Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
Subject: Re: Common accessor for private State
To: dev@zest.apache.org
References: 
 <CADmm+Ke+-8i4aSsNzLcVHs1WF7vbRCFydr4Oo7V19K2=zWgAvQ@mail.gmail.com>
From: =?UTF-8?Q?Kent_S=c3=b8lvsten?= <kent.soelvsten@gmail.com>
Message-ID: <563F08AC.2030307@gmail.com>
Date: Sun, 8 Nov 2015 09:32:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
 <CADmm+Ke+-8i4aSsNzLcVHs1WF7vbRCFydr4Oo7V19K2=zWgAvQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi Niclas

Interesting!

I have always found the syntax regarding private mixins (especially the
quite large inner classes) a bit weird. So any improvements here would
be great.

An interesting thought: Could it be possible to create a
JpaEntityAssociationStateDecorator? (not sure it is really a good idea,
might be too complicated
and integration might be better done by integrating the UOW with the
global transaction management).

Not quite convinced that core is the right place though - it probably
depends on how certain we are to get the API right the first time. So a
library *might* be better.

Can You explain why *constuctor* injection is necessary in this case?
You could be running into some chicken-and-egg-problem. Could making the
State interface static help?

?


Den 08-11-2015 kl. 04:17 skrev Niclas Hedhman:
> Gang,
>
> I tend to use private state a lot, in a hidden interface within the
> composite. I end up writing,
>
> @Mixins( PersonMixin.class )
> public interface Person
> {
>     String name();
>     Person spouse();
>
>     interface State
>     {
>         Property<String> name();
>         Association<Person> spouse();
>     }
>
>     class PersonMixin
>     {
>         @This State state;
>
>         public String name()
>         {
>             return state.name().get();
>         }
>
>         public Person spouse()
>         {
>             return state.spouse().get();
>         }
>     }
> }
>
>
> I find this being too much boilerplate and have been thinking of whether it
> should be fixed. I am proposing that we create a "Decorator" (better name?)
> all the way into the API to support this.
>
> @Mixins( PersonMixin.class )
> public interface Person
> {
>     String name();
>     Person spouse();
>
>     interface State
>     {
>         Property<String> name();
>         Association<Person> spouse();
>     }
>
>     class PersonMixin extends DefaultAssociationStateDecorator
>     {
>         PersonMixin( @This State state )
>         {
>             super( state );
>         }
>     }
> }
>
> But then, why not expand on this and support Spring-style getter/setters as
> well?
>
> @Mixins( PersonMixin.class )
> public interface Person
> {
>     String getName();
>     Person getSpouse();
>     void setSpouse( Spouse spouse );
>
>     interface State
>     {
>         Property<String> name();
>         Association<Person> spouse();
>     }
>
>     class PersonMixin extends SpringBeanAssociationStateDecorator
>     {
>         PersonMixin( @This State state )
>         {
>             super( state );
>         }
>     }
> }
>
> It is a relatively simple implementation, quite efficient in terms of
> execution, and the main question for me is where to put it;
>   a. Core API (my choice)
>   b. In a library
>   c. Keep it to myself.
>
> WDYT?