TODO?

[John Reimer]

Robby wrote:

> 
> At the end of the day, that list was meant to come across as things I'd 
> like to work on short to long term. Not necessarily griping  about the 
> state of things, or trying to swing direction. I just think that there 
> could be some size wins off the top, and with d's gc the way it is, 
> there's some considerable memory footprint wins that could be in the 
> pipeline.
> 
> But I'll try to show those wins with code, rather than keep spilling 
> about it here and go from there perhaps. Now back to getting it to build...
> 
> -Robby


You have some good points. I think we can makes some wins with dwt size 
optimization especially and perhaps some better d translation where 
appropriate (incidentally, in some situations this is already done out 
of necessity).  I think this just requires more discussion; so as you 
start playing with the port, please feel free to offer some detailed 
suggestions.  I think dwt can improve in a number of ways.

Naturally, the emphasis has been on keeping the port as similar to the 
SWT as possible because this greatly reduces the porting work load. 
But, at some point, we may decide what other systematic D language 
mechanisms may prove useful to DWT.

One example of a simple improvement would be translating all instances 
of "public static const int" to an D enum type for library size 
optimization (although the size reduction may not be all that 
significant).  The java const ports straight across to D but is entirely 
suboptimal for DWT because it unnecessarily bloats the D object file 
with symbols. A better translation would be to use a manifest constant 
in the form of an "enum". Furthermore this will eventually ease the port 
to D 2.0 at some point.

There are still other improvements that I'd like to see. As you 
mentioned, I do believe adoption of D dynamic arrays may be useful in 
several situations.  Although in others, the dwthelper utilities 
implement java equivalent array copies which is arguably better than 
using dynamic arrays because many of the instances represent overlapping 
copies (which D arrays don't do).

Concerning struct uses, I'm not aware of too many situations where this 
may be useful.  We've already converted some of the simpler POD to 
structs because they were merely copies of internal platform ones.  But 
there may be some lingering situations still available.  One I can 
immediately think of is GLData... there may be several others that I 
haven't thought of.

Suggestions are welcome.

-JJR