Refection vs Code Generation

I've changed the Subject line in this reply to reflect the new topic.  This 
was formerly about JPanel graphics. 

There are certainly cases where the dynamic (runtime) construction of a GUI 
using refection, as Swixml currently does, is necessary.  Kate gave an 
example, and I'm sure there are plenty of others. 

One question is whether there are also advantages to generating code, other 
than a little execution time saved at runtime, which doesn't seem to be much 
of a problem for most users. 

A serious deficiency of the current reflection approach is that the values 
of the attributes are seriously limited.  For example, to specify the 
background color of my JPanel, I would like to be able to used attributes 
like
   background="Color.WHITE"
   background="new Color(45, 200, 255)"
   background="new Color(0xFFAAAA)"
None of these work with Swixml, and it's hard to see how to make some of 
them work, or even worse, calls to get system colors.  [By the way, what 
Swixml does allow is background="FFAAAA".]  I see this as one of the serious 
weaknesses of Swixml as more and more work must be put into attribute 
conversions. 

Simple text substitution could be used to map most attributes of the form
   xxx="yyy"
into Java code like
   comp.setXxx(yyy); 

This provides features that Swixml can't.  So the code generation approach 
is not simply a subset of the reflection approach - it has its own 
strengths. 

At my early learning stage I haven't used many of Swixml's features, so 
perhaps my simple static GUIs haven't given me enuf appreciation of its 
reflective capabilities to overcome the constant pain of attribute value 
hassles.  At this point I'm leaning toward the advantages of code 
generation, but will continue to try out new features of Swixml in the 
expectation of finding more goodies. 

 -- Fred 


Frank Meissner writes: 

> Hello Fred, 
> 
> [email protected] wrote:
>> Hi Frank, 
>> 
>>> Regarding your offtopic-subject: There is always the tradeoff between 
>>> flexibility and performance. The changes you suggest improve neither. 
>>> Please do'nt be offended, though...
>>  
>> 
>> It would certainly seem that removing the XML interpretation/reflection 
>> layer should improve performance -- not that I have any complaints about 
>> Swixml performance, which I think is quite satisfactory.  Because you 
>> don't agree on something that seems obvous, we're probably working with 
>> different assumptions.  Maybe I'll find some time in the future to create 
>> an example of what I mean.
> 
> Oops, I did not make myself clear here. Removing the 
> reflection/interpreation part *would* improve performance, agreed. 
> 
> I meant the changes you originally suggested. BTW: I thought about 
> removing some reflection code myself (replacing it with generated code), 
> leaving reflection as "last resort" ;) 
> 
>> And I'm certainly not offended by disagreements with constructive intent 
>> -- hope you feel similarly.
> 
> Glad to hear :) 
> 
> Frank 
> 
>> -- Fred 
>> 
>> _______________________________________________
>> Forum mailing list
>> [email protected]
>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com 
>> 
>  
> 
> 
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com