Le 2017-04-11 08:23, Niclas Hedhman a écrit :
Gang,
I figured out what was going on with the ValueType not containing
ValueComposite.class for a ValueComposite in a Property of something
else.
It was as I suggested a matter of only checking interfaces during the
building of the composite models, and hence not looking at any
registered
types.
But this made me wonder....
module.values( List.class ).withMixins( MyList.class );
Property<List<String>> nicknames();
Is nicknames now a ValueComposite or not?
It is simply a matter of we have no strong definition when an interface
"becomes" a ValueComposite.
And I have no good answer either (mostly because of the sample above),
but
I think we need an answer "now".
And when does this matter; Well, at the moment I can only think of
indexing/query and deserialization of entities (again, should a HashMap
or
a MyList be attempted above?)
Cheers
It's not a definitive answer at all but I would say that a type
assembled as a value is a ValueComposite:
module.values( SomeType.class, List.class );
They are required to be assembled as such to be used in state modeling,
e.g.:
Property<SomeType> someProperty();
Property<List<Whatever>> someOtherProperty();
The ValueTypeFactory would then provide a ValueType which is the thing
used by consumers to take decisions.
As of today, the two methods of ValueTypeFactory will return different
things for List ... hum hum.
Either a ValueCompositeType or a CollectionValueType.
We clearly need to make this smarter once we know what to do.