On Jun 25, 2012, at 11:30 AM, Niclas Hedhman wrote: > Right, I was more thinking of disallowing java.util.Date/Calendar and > FORCE people to either JodaTime or JSR-310. > > On Mon, Jun 25, 2012 at 4:50 PM, Kent Sølvsten <[email protected]> wrote: >> >> And then we simply allow a value to contain types, that are known to be >> immutable, or known types which we can handle more or less this way. >>
I use custom value types often, i.e. Money . If you restrict custom types I will have to create MoneyValueComposite and my money manipulation code will bloat. If you allow custom types ( as it is now), I am afraid there is no way to force immutability except clone on set/get. ( assuming type must implement clone() ) Maybe education is right way and during app assembly report usage of java.util.Date as warning. one think related to VC immutability: VC allows to contain Associations. get() on such association uses current module uow. This get() always goes to uow, second call will return the same entity from uow cache. But if current uow changes, my immutable VC will get me another entity instance. I am caching entity in AssociationInstance in my patched qi4j ( but I had another another reason for this ). cheers, Tibor _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
