On 2010-07-06 19.10, Edward Yakop wrote:
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.
Note that we are primarily talking about the case where we have an
entity already defined, and we want to add more methods to it, rather
than add more implementations of existing methods.
Actually, we definitely need a new method in the assembly API, because
.withMixins() is supposed to add lists of mixins that are available as
implementations, whereas what we discuss now is almost exclusively about
adding new methods, i.e. the class being added needs to be an interface,
not a mixin class.
So, one would do:
module.addEntities(DomainFooEntity.class).withRoles(Some.class).withMixins(SomeMixin.class);
where Some is the interface with role methods, and SomeMixin is the
implementation (if I don't like the default in Some or if there is no
other declared implementation).
In general, to keep things aligned with DCI, I think I'd prefer
"withRoles" instead of "withAbilities" as previously discussed. What do
you think?
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?
That's for the implementation part, yeah.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
