Taking it one step further...
Looking at the methods in Composite, TransientComposite, ValueComposite
and EntityComposite, a majority of them are duplicated in SPI.
In Composite:
public interface Composite
{
<T> T metaInfo( Class<T> infoType );
Class<? extends Composite> type();
}
can be just as easily done through Qi4jSPI by getting the descriptors.
In Value (which ValueComposite extends):
public interface Value
{
StateHolder state();
<T> ValueBuilder<T> buildWith();
String toJSON();
}
---
state() is in Qi4jSPI, buildWith() is equivalent to
ValueBuilder.withPrototype(), and toJSON() is now a pure delegation to
JSONSerializer anyway.
EntityComposite extends Entity (no methods) and Identity (only has the
identity() property). Identity could easily be added as a role, for the
rest, see above.
In other words, there are no methods now in the *Composite interface
that really warrant them being extended, as a core design decision.
If getting ahold of the Qi4jSPI instance to get descriptors etc. is too
tricky, then the following code can always be done as a workaround:
ValueDescriptor valueDescriptor = (ValueDescriptor)
((CompositeInstance)Proxy.getInvocationHandler( value )).descriptor();
as CompositeInstance is now in API and the descriptors are in SPI.
The only remaining function that the interfaces provide is the supplying
of the default mixins (e.g. PropertyMixin, IdentityMixin), but that
could easily be done by Qi4j automatically.
What say ye?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
