But then Foo should be immutable (which would be a great thing in such a model anyway and there you go).
I heartily recommend the date & time api podcast with regard to architecture, immutability and types for concepts. http://parleys.libsyn.com/index.php?post_id=314147 Not using the meta-information available in the properties is ok for the core model. If you think further into generators / editors for qi4j applications having properties with the meta-info there would help (but that layer could also be provided using decorators or type adapters). For the Properties I think the other way round would be better. I'd also love to have a ImmutableCollection in the java collections api on which the normal collection is based, so all those mutable collections could just be casted/wrapped to the immutable interface implementation without reverting to throwing UnsupportedOperationExceptions. Michael Rickard Öberg wrote: > Michael Hunger wrote: >> Sounds sensible altough I'd surely taken the other way round, perhaps >> starting with one interface (perhaps with generics for the concept) and >> only partioned it if needed. > > Yeah, that might make sense, since there's little reuse anyway, i.e. the > mixin interfaces are not reused at all since they are all different at > all levels. > >> Why are the properties of the model mutable? Shouldn't most of them be >> derived, precalculated properties that come directly from the used >> interfaces, concepts, mixins, classes etc. > > The properties aren't mutable, hence the possibility at least to use > ImmutableProperty. But not sure what the value of using > "ImmutableProperty<Foo> someProperty()" over "Foo someProperty()", since > we're not using anything from the Property API anyway. > >> So I'd rather opt in for not using mutable properties at all for these >> attributes. I don't recall right now is Property based on >> ImmutableProperty or the other way round? > > ImmutableProperty extends Property, where set() cannot be called. > > /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
