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