Ok for the @IgnoreWarning(Insane).
I think that many IDE, even eclipse, tries to track null variables and
in this specific case, @This is not initialized (an eclipse does not
complain BTW).
The qi4j learning curve is steeper with @This, but it's no big deal
really... Is there a requirement linked to this or could it be
postponed after 1.0 ?
phil
Le 18 août 2009 à 16:50, Niclas Hedhman a écrit :
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
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
