Quoting Rickard Öberg <[email protected]>:
On 2010-03-05 18.05, Stanislav Muhametsin wrote:
Since org.qi4j.spi.property.ValueType already has method types() , which
is only interesting for ValueType's representing ValueComposites, could
it also have collectedType() from org.qi4j.runtime.types.CollectionType
? That way I wouldn't need to reference org.qi4j.runtime.*
packages/classes. It could return null for all other except
CollectionType. Alternatively, you could make CollectionType return
collected type in types() -method. Whichever works better for you. :)
I've looked into this a bit. So, in a sense it is bad that we only
expose ValueType in the API, and the rest is in runtime, since it
forces us to expose methods in ValueType that really depends on what
kind of type it is.
Should we try to move these into API instead? Or should we have
duplicates, i.e. an interface in API and then the current
implementation stays? Maybe that would be the cleanest way to do it.
/Rickard
That could be a possible solution. And would be a good practice anyway.
For my part, I already circled the problem by using PropertyDescriptor
instead of PropertyType. Actually, I remember someone saying that
EntityType (and Property/Association/ManyAssociation -Types) and
EntityDescriptor (and Property/Association/ManyAssociation
-Descriptors) being duplicates of each other, which evolved there
during some phase of Qi4j development. And that the XXXType:s should
be merged into XXXDescriptor:s.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
