What is a ValueComposite?

[Niclas Hedhman <ni...@hedhman.org>]

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
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: What is a ValueComposite?

[Niclas Hedhman <ni...@hedhman.org>]

And there is the thing that the same interface can be different valuetypes
because registered in multiple modules, which furthers complicates the
definition. Yet, we let the interface "be" the value type in many
instances, regardless of the declared ValueModel.

I think that there is an inherent problem in these things, that just happen
to be "quite good" but not actually accurate, and it shows itself in corner
cases...

So, I think the "proper" way should be to be consistent;

    TypeLookup lookup = module.typeLookup();                   //
TypeLookup is "in charge" or everything

    ValueDescriptor<Abc> model = lookup.lookupValueModel( Abc.class );  //
The model has all the needed details

    ValueBuilder<Abc> builder = vbf.newValueBuilder( model );  // vbf
should actually take a model

    Abc abc = builder.newInstance();

    ValueDescriptor descr = api.valueDescriptorFor( abc );     // and we
can get the model back from an instance


I think this is actually happening under the hood for the current creation
of a builder, but that should be a convenience and not the formal way.

BUT, if a ValueComposite type MUST be backed by a ValueModel, I think we
still have work to do for nested types of interfaces, which sometimes are
dealt with via the ValueModel, and sometimes just another Java type, as
seen in the indexing-sql testcases, and probably was the reason for the
value finder (or whatever it was called) in previous
indexing-elasticsearch. The lambdas around traversing types are probably a
little bit guilty of making that relatively simple operations to do, and
skipping the models by oversight and convenience, especially since most
things works anyway.


Not sure what I think about it. On one hand it is a sore imperfection that
I don't like, but start digging in it is uncertain to how much effort it
would take.

Cheers
Niclas


On Sun, Apr 23, 2017 at 8:33 PM, Paul Merlin <pa...@apache.org> wrote:

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


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: What is a ValueComposite?

[Paul Merlin <pa...@apache.org>]

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.