Hey,
If a mixin implements an interface, but is marked as abstract, it has
until now been required that it uses @This injections in order to call
the rest of the methods. Also, if a mixin calls another public method
which is a part of the composite interface, then one would have to use a
@This injection to make sure that the call went through the proxy (and
concerns/sideeffects).
Today I have been experimenting with allowing mixins to call methods
that are not implemented in abstract mixins, and have them be
automatically routed to the composite. Similarly, if a mixin calls
another method it is automatically routed through the proxy without the
mixin having to do anything.
Example:
interface Foo
{
String some();
String other();
}
abstract class FooMixin
implements Foo
{
public String some()
{
// No need to do "@This Foo foo;"
return other();
}
}
---
The pro's of this is that it becomes very easy to access other parts of
the composite. Basically you don't need to use @This anymore. Just
implement interface and mark mixin as abstract. Another pro is that
public methods will always have their concerns executed. But, are there
some times when you don't want them to be? If so, when/why?
The main con of this is that it requires Qi4j to subclass eeevery
fragment class using CGLIB, and this causes quite a bit of extra memory
usage. In fact, as I am trying this out the qi4j-extensions package
isn't even building right now due to OutOfMemory errors!
I'm not sure what to do. Is this important enough that I should continue
and make it work, or is it just "fluff" that we can do without?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
