Niclas Hedhman wrote: >> Instead, my current thinking is >> that the best pattern is to use private mixin types for it. > > Yes, that works. Question is if we should enforce it? Or perhaps have > a global option to enforce that properties are not exposed in > Composites. > (Q; Why doesn't fields work? Is it about inter-Mixin access? )
Yeah, inter-mixin access was one of the main things that seems to get screwed up. The Query API is another, which would totally break down with field-declarations. > Visitor pattern is IMHO a good choice. And with COP/Qi4j, one can add > the implementation "after-the-fact" with another MixinType (@MIxins > and @Concerns). One small con is that "sub systems" are never really > "untouchable" but will become much more like Lego where someone > provides a lot of nice bits and pieces, but you typically need to > assemble them yourself. Yup. We'll get "DomainEntity" and then "MyUIDomainEntity" which does the mapping to the particular UI. > In general, I think you hit on a weak spot, and frankly I have not > spent any cycles over it before. I also have a GutFeeling that if this > is enforced, we will get a lot of initial flak. People are so used to > the "query and navigate" object structures, that it is hard to > change... Agree. Like I said, maybe we can have usage patterns that gets around it, and that will be fine. Not sure yet. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
