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.
Michael Niclas Hedhman schrieb: > On Mon, Jun 9, 2008 at 6:25 PM, Rickard Öberg <[EMAIL PROTECTED]> wrote: >> Niclas Hedhman wrote: >>> Well, I was thinking that even Jini Services are backed by a >>> ServiceComposite, otherwise we have too much messy code. >> Is there anything in particular that will be too messy? AFAICT right now >> there is no absolute need for this. The only minimum requirement is that >> there's an interface, so that we can create a proxy. Is there anything >> specifically about it being a ServiceComposite that you see as required? > > Only that the registration process is "unclear" at the moment. I also > want to avoid the "abstract away reality because we can" ;o) > > >> Ok, what I should have said was that Composites do not have >> Associations. Entities currently have, and ValueComposites should have >> in the future. Then the above is ok I think. > > Maybe. It might depend on the outcome of Composites vs ValueComposites > vs SomethingElseComposite discussed below. Point is, we need to allow > domain models to have associations even if the domain model will not > be used with persistence layer. > >> Well, in that case the whole framework is exclusively geared at >> enterprise apps, i.e. there's no way to do a POCO (Plain Old Composite >> Object). ValueComposites would have restrictions (such as immutability) >> that Composites currently do not have, which I think is bad. > > Good point. > But, my main point was perhaps more towards making "Composite" an > "abstract interface" (or perhaps even "gone" although I doubt that), > from which one can not create composite instances, but must use a > qualified subtype each with more well defined semantics. > What I am thinking of is that, you can't say that "This is an > instanceOf Composite, therefor the semantics are the following....", > but you have to put it with a bunch of "unless it is an instanceOf > ServiceComposite and unless it is an instanceOf ....". I think for the > sake of documentation, it would be better to have concrete subtypes > that don't inherit/modify semantics from each other. > > > Cheers > Niclas > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
