Niclas Hedhman wrote: > I disagree with that too. There MIGHT be an entity. An HttpRequest > could be seen as a Value without holding Entity, for instance.
Actually, HttpRequest is a bad example since it has setAttribute(). But I see your point though. > 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. Points well taken, and I agree with what you're saying. As an aside, as I am working on Values right now I am also refactoring the models so that for everything there is Abstract* as base model and then Value*/Entity*/Composite* for the specific versions. For example, ValuePropertyInstance then lost its reference to constraints (since it cannot be changed anyway!), and so became more lightweight in terms of memory! Lots of other similar neat sideeffects of this refactoring. I hope to complete it today... I have just gotten to work that Entity->Value->Value can be persisted to MemoryEntityStore by having it persist EntityState->ValueState->ValueState. Working on the reverse right now (i.e. "inflating" ValueState into ValueComposites). One thing though: the DefaultValueState includes type information, so when serialized it is quite verbose in its persistent format. We may want to fix this later, BUT there is a point to it in the sense that full type info is then retained, which could be useful for migration purposes. Something to think about. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
