Not so sure it will help tools, since if they were smart they would have no clue what is going on and mark the programmer 'insane' without delay.
My worry is the number of classes. We already see quite a number, espcially with role/state separation, and with this it will at least double the number of runtime classes, depending on how good you are with reuse of fragments in different composites. On one hand, I would promote that the subclassing only occurs if the fragment is abstract (or perhaps not final or not private), so that one can avoid the explosion if it matters. BUT OTOH, that would give rise to problems explaining, trouble-shooting and maintain the code since it seems less predictable... I have no strong opinion either way. With @This one can handle all cases, with the BC manipulation you are always stuck on 'plenty of memory'. Perhaps that tip the scales for me slightly in favor of @This. -- Niclas On Aug 18, 2009 7:33 PM, "philippe van dyck" <[email protected]> wrote: Le 18 août 2009 à 13:19, Rickard Öberg a écrit : > Hey, > > If a mixin implements an interface, but is marked as abstract, it has until now been re... Sounds perfect for me, I sometimes forgot to call @This, now I am used to, but if I could get rid of it =-> +1 I think that it will also help findbugs, metrics and refactoring tools understand more what's really happening behind the wheel. my 2 cents, Philippe _______________________________________________ qi4j-dev mailing list [email protected] http...
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
