Michael Hunger wrote: > So having the base composite internally and delegating to it would not create > inheritance dependencies. > Regarding the base composite type. The question is if this unqualified type > is needed. If you look at java perhaps the > question if its sensible/possible to instantiate objects (Object.class) is > sensible. What would you need the most > abstract basic type for. I'm with Niclas in that. > What shall be easily possible though for the end user is to provide a > "subtype" of composite that fits their need with > their sub-composite-interface + mixin for that.
And right now we have sort of started this, with the EntityComposite subtype, and also the ServiceComposite subtype. But, there is a big difference between a service and a server. A client asks for a service to be injected (or looked up through ServiceFinder), not a server, and if what is provided is a direct implementation of that, such as a ServiceComposite, or whether it's hidden behind ten layers of proxies, should not really be important. The final implementation should, in a Qi4j-world, be a ServiceComposite, yes, but if we look at the possibility of having many Qi4j Applications, where a fragment wants a service injected, and then the actual implementation of that is in an Application running remotely, then we need to ensure that the service injection scheme locally does not require that the injected object is a ServiceComposite. It will be, on the other end, but not in the actual VM where a reference to it (or a proxy to it rather) is injected. Do you see the difference? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
