On Tue, Feb 17, 2009 at 3:56 PM, Rickard Öberg <[email protected]> wrote: > Niclas Hedhman wrote: >> You see ValueComposites as DTOs, which I disagree with. There is >> nothing inherent with Values that makes them "dumb value container", >> and if we are to follow the general guideline, "Avoid Entities as much >> as possible, and only introduce if the life cycle of it must be >> tracked." then a vacuum arises and TransientComposite must be used >> (which means complex persistence). > > Ok, but even if you add methods to Values, there is still no real need, > as far as I can tell, to have private state in Values. There *will* be > an entity holding on to it (right???), which can do private things, if > needed.
I disagree with that too. There MIGHT be an entity. An HttpRequest could be seen as a Value without holding Entity, for instance. I have for long been promoting "Immutable, anonymous objects", although I wasn't that clear to call them Values until a few years ago. I don't think that State is required to be more public for a Value than it is for an Entity, although I think it will be more *common* that there is public state in Values than there should be in Entities. If we dig deep into the implementation details on how to do ValueComposites, I think we should support the full spectrum of today's Composites with the Immutability restriction and automatic equals() handling. BUT that we can optimize later for the light-weight ValueComposite case, since it will be important for overall memory consumptions, but as I see it "Make it Run, Make it Right, Make it Fast." we are only in the "Make it Right" stage at the moment. Cheers Niclas -- http://www.qi4j.org - New Energy for Java _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
