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.
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. 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? Michael Rickard Öberg wrote: > Hey, > > FYI, for the internal model I am now using the approach that each > concept (Layer, Module, Composite, Mixin, etc.) has > XComposite,XModel,XResolution,XBinding,XContext interfaces, where > XComposite extends the other interfaces, and then a XCompositeMixin > which implements XComposite. I.e. an extremely simplistic composite > model which isn't even based on composites internally since it's only > one mixin. However, I hope that this will still be useful as a way to > separate the methods into appropriate "slots" (the different types of > interfaces). Also, it is entirely possible that for example XBinding > might be replaced with a generic Binding interface, since at least right > now all of them only contain the method "bind()". > > Not sure if it will be confusing to call it XComposite since it will > internally only be one "mixin", but I'll try anyway. > > Also, I'm opting to not use ImmutableProperty in the model (e.g. for > CompositeComposite.type()). It doesn't seem to buy anything right now. > If anyone has good reasons why to use it anyway, let me know. > > /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
