On 2009-12-05 20.35, Stanislav Muhametsin wrote:
Aah, well, I guess what is difficult for others is easier for anothers.
I thought it would have made it clearer to separate code into three
sections:
1. The API definition (only interfaces)
2. The API implementation (only possible internal interfaces +
implementing classes, possibly many different implementations for same
thing, concentrating on security/efficiency/etc)
3. The mapping between defintion and implementation (done, for example,
at assembling stage). Thus, whoever creates the mapping, can choose
between more secure/efficient/etc implementations. The API creators nor
implementators need to worry about declaring which mixin/concern
implementation is used, only the creators of mapping would need to worry
about that.
It is true though, that it would make things more difficult, and
possibly benefits might not be worth the effort. Hard to say, as this
again depends on so many factors. I guess if someone really wants the
described separation, can always just leave out all the @Mixins(...) etc
annotations out.
It depends on what you want to achieve. When I use interfaces on
Entities for roles, I want to minimize polymorphism as much as possible,
and so I use @Mixins declaration with a default implementation right
there on the interface. When I use service interfaces I may want to have
several implementations, and then the ServiceComposite that actually
implements the interface has the @Mixins declaration. Right now I don't
have any cases where the mixin selection is better done in assembly, but
that might come with more customer-specific scenarios (which I will
avoid as much as possible, and use a plugin-style option instead if
possible).
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
