But wouldn't it be sensible to have property for serializable values and association for non serializable ones?
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). In general I'm pro values containing references to entities (in accordance to aggregate rules). 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). 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. Michael Am 12.01.2009 13:39 Uhr, schrieb Rickard Öberg: > Niclas Hedhman wrote: >> On Mon, Jan 12, 2009 at 5:17 PM, Niclas Hedhman<[email protected]> wrote: >> >>> Suggestion; >>> "The generic type of a Property must be a fully Serializable type, and >>> must not have any injected members." >> Actually, it is not the type that needs to be Serializable, but the >> instance that is assigned to it. >> This poses the question; Should we require the type to be Serializable >> and change the Property definitions to >> >> public interface Property<T extends Serializable> >> extends PropertyInfo >> >> or should we require the set() method to do the check and fail if the >> instance is not Serializable, >> >> or just let things fail 'late'? >> >> >> I am in the position of the first, purely because I love compile time >> support. > > Well, I think we had this at some point, but it's annoying if you want > to use interfaces for the type, e.g. java.util.List. You would have to > set the type to ArrayList, or any other concrete class, which is bad. > Also, it makes sense for Properties in Entities to be serializable, but > not necessarily for Properties in Composites, which could be literally > anything without any problems. > > /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
