Hi Rickard, I still use the @This annotation and recently switched to the latest version with ASM. My application lost at least 1/3 of it's memory usage and looks more responsive. All the concerns I use are "out-mixin" calls. Could you please explain what you mean exactly by "subclass *every* mixin, not just the abstract ones" ?
cheers, phil On Fri, Jun 4, 2010 at 6:30 AM, Rickard Öberg <[email protected]>wrote: > On 2010-05-31 16.08, Rickard Öberg wrote: > >> I had to remove a couple of tests, since the new generated classes >> behave a little differently. I do not subclass concrete methods, only >> abstract ones, which causes slightly different behaviour when one method >> calls another (=no concerns/sideeffects are invoked). Other than that >> all tests pass. >> > > Well, that didn't work out well. Turns out pretty much every line of code > in Streamflow assumes that concerns are executed even on in-mixin calls. > Damnit. > > 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: > > public void bar() > { > foo(null); // Null should not be allowed > } > > // someString is not @Optional > public void foo(String someString) > { > } > > With the above, the null-check would only be done if the call is made like > so: > @This MyInterface myself; > > public void bar() > { > myself.foo(null); // Will throw exception > } > > I guess this is pretty strong in favor of always doing subclassing of > methods. But then we need to subclass *every* mixin, not just the abstract > ones. > > Thoughts on that? > > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev >
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
