polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <hedh...@gmail.com>
Subject Re: Common accessor for private State
Date Sun, 08 Nov 2015 14:18:29 GMT
On Nov 8, 2015 16:32, "Kent SĂžlvsten" <kent.soelvsten@gmail.com> wrote:
>
> 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.

Well, you don't need to make the private Mixins as inner interfaces. Works
equally well with top level interfaces, it is just I who think it is
convenient to have everything in the same place.

> 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).

A little bit hard to see the complications. Are you talking about a Zest
entity composites behaving like JPA persistence capable beans?? Or the
other way around?

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

Yeah perhaps that is a good reason.

> Can You explain why *constuctor* injection is necessary in this case?

Two things are required. Something needs to have a @This declaration,
otherwise the state isn't brought into the composite.
Secondly, whatever does the mapping needs a reference to that private
mixin, primarily for performance reasons. Well, I guess an abstract method
would also work...

class PersonMixin extends DefaultAssociationStateDecorator
{
     @This
     private State state;

     protected Object state()
     {
         return state;
     }
}


> You could be running into some chicken-and-egg-problem. Could making the
> State interface static help?

Doh... interfaces are always static. As mentioned earlier, there is no
"bond" between the "interface State" and its containing class. The link
happens with the @This annotation on either a field or
parameter/constructor injection.


Niclas


> 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?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message