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
