You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2015/11/08 04:17:37 UTC
Common accessor for private State
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?
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Common accessor for private State
Posted by Niclas Hedhman <ni...@hedhman.org>.
So, for @This injection in fields, the type is somehow added to the
Composite, but when it is injected in the Constructor, it seems to only
take the public Composite type interfaces...
On Mon, Nov 9, 2015 at 2:06 AM, Kent Sølvsten <ke...@gmail.com>
wrote:
> Den 08-11-2015 kl. 15:18 skrev Niclas Hedhman:
> > 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?
> I was thinking along the lines of using a Zest-unaware JPA Entity as
> underlying state of en EntityComposite - but i suspect that we would be
> up for some unpleasant surprises.
> Especially since JPA sometimes wish to autoflush stuff.
> >> 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 should be able to do it without the method (iterate all fields of
> "this" class and check for annotations, but not very nice - the getter
> is better) - but i agree it would be nice to have constructor injections
> work.
> Both for your case and generally.
> I am unfamiliar with this stuff .... what exactly is not working? Is it
> all constructor injections on private mixins, or just @This injections?
> (could give a hint where to look for a solution)
>
>
>
> >> 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.
> I actually didn't know that - soooo obvious in hindsight! I was just
> thinking if there could be some type matching not taking place.
>
> /Kent
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Common accessor for private State
Posted by Kent Sølvsten <ke...@gmail.com>.
Den 08-11-2015 kl. 15:18 skrev Niclas Hedhman:
> 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?
I was thinking along the lines of using a Zest-unaware JPA Entity as
underlying state of en EntityComposite - but i suspect that we would be
up for some unpleasant surprises.
Especially since JPA sometimes wish to autoflush stuff.
>> 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 should be able to do it without the method (iterate all fields of
"this" class and check for annotations, but not very nice - the getter
is better) - but i agree it would be nice to have constructor injections
work.
Both for your case and generally.
I am unfamiliar with this stuff .... what exactly is not working? Is it
all constructor injections on private mixins, or just @This injections?
(could give a hint where to look for a solution)
>> 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.
I actually didn't know that - soooo obvious in hindsight! I was just
thinking if there could be some type matching not taking place.
/Kent
Re: Common accessor for private State
Posted by Niclas Hedhman <he...@gmail.com>.
On Nov 8, 2015 16:32, "Kent Sølvsten" <ke...@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?
>
Re: Common accessor for private State
Posted by Kent Sølvsten <ke...@gmail.com>.
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?