On 2010-06-04 18.41, Niclas Hedhman wrote:
On 6/4/10, Stanislav Muhametsin<[email protected]> wrote:
Quoting Rickard Öberg<[email protected]>:
So now there's a decision to be made:
Either calls within a mixin will cause concerns to be invoked, or
not. If not, then to force them to be invoked you have to do a @This
injection and then call that instead, to ensure that the call goes
through the proxy.
What makes the most sense? I guess we have to also remember that
code like this will not work if methods are not routed through the
composite within the mixin:
In my app, I'm also invoking all my calls to "myself" through
@This-injected fields. IIRC there was some tutorial or something on
the qi4j.org site, which urged to this kind of behaviour, saying
specifically that if i just to "this.foo(...)" it might not execute
mixins. Guess someone was a psychic. :)
That is because originally (2007) we didn't have any Magic. IIRC,
first came the abstract fragment which got subclassed and much later
the in-mixin method call interception. So it is a matter of out-dated
docs.
Right. So the question is: do I opt for a consistently magical model
(where in-mixin calls are routed through proxy), or should I only "fill
in" abstract methods that are missing? Then if you want
concerns/sideeffects/constraints to be invoked you *have* to use a @This
injection.
I'm looking through the code-generation now, and it was actually easy to
add the "_" prefixed methods. What is not so easy is to get them to be
called throughout the proxy chain, but that's mostly a matter of hacking it.
But should I continue that or not is the question. What do we *want*?
For myself, we exploit the fact that in-mixin calls are routed all the
time, and would have to change every single mixin if we remove the
CGLIB-semantics. But.. I don't know. Again, what do we want? What gives
the least surprise, I suppose?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
