Michael Hunger wrote: > But wouldn't it be sensible to have property for serializable values and > association > for non serializable ones?
Sure, but that doesn't change the fact that setting the type to "? extends Serializable" has the problems I outlined. > On my way home I was thinking about the problem Rickard just mentioned - > create new instance of values when changing just one property. I think to get > around > the problem it would be nice to have built in support for that. > So that a entity.value().property().set(newPropValue) would automatically > create > a new value and reassign it to the entity's property. (With the help of a > builder > that internally copies the state of the value and changes the single property > during > that process). Since I hope you're not saying that the value() should have a reference to its owning Entity this would mean creating another layer of proxies on top of the Value, right? And with the above syntax this would have to be used ALL the time, even when the access is read-only, as it will be most of the time for Values. If yes, the I am so -1 on that one. Overcomplicated and underperforming. I think it's better to simply allow the factory for values to take an existing value to use for initial property values. Something like: ValueBuilder builder = vbf.newValueBuilder(entity.value()); builder.stateOfComposite().property().set(newPropValue); entity.value().set(builder.newInstance()); This reuses already known patterns, allows you to change several properties in one go, and has less magic to it. > In general I'm pro values containing references to entities (in accordance to > aggregate rules). But there's no way to check those aggregate rules if all you have is values, since values has no reference to the owning entity. > In principle the value type is defined by immutability, no lifecycle, no > identity and equality > based on contained/refernced values (I hope I didn't forget anything). That's the basics, yes. But as above, we might have to have more rules for practical and principal reasons. > Regarding interfaces like List and Serializable. I'd rather prefer concrete > collection types > derived from domain concepts than generic collection types which bring their > own lot of problems. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
