Reply inline. On Tue, Jul 6, 2010 at 16:52, Rickard Öberg <[email protected]> wrote:
> On 2010-07-06 15.20, Paul Merlin wrote: > >> Hi Rickard, >> >> I use assemby time mixin declaration .withMixins() (implementing the >> composite >> or for private mixins) and don't want all their public method to be added >> to the >> interface of the composite. >> >> If I understand your proposition, this won't be possible anymore ? >> >> As I do DCI I understand the issue but maybe we need a smarter assembly >> api >> here. >> >> .withMixins(...); >> .withPublicMixins(...); >> > > Yeah, it might be that we need to differentiate between them, as you > describe. > > But what about the general idea? Does it seem ok? > > We had a meeting in my project about this just now, and the main thing we > concluded was that *if* assembly is the place to put this, then it has to be > done where the context is defined, not where the entity is defined. Of > course, this could probably be done with a helper utility. > I'm not really buying the "configuring mixin in assembly" concept. If I'm implementing a mixin, I obviously have a certain assumptions on available mixins in order for implementation to work. Having this mixin declared in the interface certainly communicate my intent better, promote reusable component by providing default implementation. The question that I have with .withMixins(), .withPublicMixins() and mixins declared on the interface. What would be the order of which mixin to invoke when a method is implemented by many mixin? assembly first -> child interface mixins -> parent interface mixins? Do we allow both concerns and side-effects to be configured via assembly? *shudder* Regards, Edward Yakop
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
