I also agree with Niclas. There is no point in restricting values to be structs. The power of expressive values is not to be underestimated.
Regarding the possibilities of values and their equality perhaps we can take some points from scala's case classes? Those embody the structure of their creation and this information is also used for equals etc (was this other thing constructed the same way as me). (As a side note: This is also used for functional pattern matching and accessing the construction time information.) Regarding the persistence of values. If the type information take too much room we still can provide a custom serialization and have a lookup table for type information which is stored within the serializing store as well (saved on update) and reloaded on startup. Michael Am 17.02.2009 9:32 Uhr, schrieb Rickard Öberg: > 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 _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
