I have no strong GutFeeling(tm) either way on this. But perhaps slightly more inclined towards;
* All declared concerns and side-effects are executed for public methods regardless of where the call is originating from. Seems to be easiest to explain that way. On 6/4/10, Rickard Öberg <[email protected]> wrote: > 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 > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
