I'd also support that. I thought we already discussed that possibility with
withConcerns().
I don't think this goes agains readability as a lot of interfaces just for the sake of adding another mixin (especially
if we go to the UI / Server specific extensions to core domain objects) is more readable than having all extensions in
one place (the assembler). So you can look at it and its relationships without browsing through a plenthora of interfaces.
Just my 2 ct.
Michael
Am 20.02.2009 3:51 Uhr, schrieb Rickard Öberg:
Niclas Hedhman wrote:
I think that the Context Modifiers has the need, since if they declare
a Private Mixin, there must be something that implements it, and a bit
unlikely that it is present already in the underlying Composite.
Agree! So, the feature has to be there, to support .withConcerns(), if
nothing else...
Whether there is a need for overriding public mixins or not, I have
currently no clue.
Right. I would avoid it if possible, but the feature will be there at
least given the above.
I'll add it. It's trivial to implement.
/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
