[news.eclipse.platform.swt] Re: "Temporary code" inside swt.graphics.Dev

["Steve Northover" <steve_northover@xxxxxxxxxx>]

This is cool.  The obvious problem with not having some kind of automatic
translation strategy is that you won't get bug fixes.

"verec" <verec@xxxxxxx> wrote in message
news:dakdef$t5o$1@xxxxxxxxxxxxxxxxxxx
> On 2005-07-05 20:43:06 +0100, "Steve Northover"
> <steve_northover@xxxxxxxxxx> said:
>
> >> SWT 3.1 (3138) as part of the newly released Eclipse 3.1
> >> still reads, at the top of Device.java
> >>
> >> /*
> >> * TEMPORARY CODE. When a graphics object is
> >
> > The "temporary code" is here to stay.
>
> Too bad :(
>
> >  Are you automatically translating the code?
>
> No. By hand. One class, one method at a time. Painfully slow.
> But the only solution I know of if I want to know the system
> inside out, at least on OS X. And if I want to make it fit
> with the C++ "runtime environment" (eg: std::string, PThreads)
> the way the Java version does fit with Sun's JRE ...
>
> So far, the "hurdles" I had to overcome include:
>
> - Garbage Collection (that's a _biggie_) including Java
>   pointer semantics (Java calls those a reference, but
>   that's really a pointer that happens to use the dot
>   syntax) which have nothing to do with C++ references,
>   and do clash a bit with the "STL induced" generic school
> - derived methods called from base constructor (adhoc,
>   nearly transparent solution)
> - builtin arrays as Object (solved through templates)
> - class.forName() as in the temporary code (this particular
>   instance wasn't _too_ hard to "fix", but I don't have
>   a general solution)
> - replaced most of java.util.* with the STL and/or custom
>   templates
> - replaced java.lang.String with std::string
> - replaced java.lang.Thread with a thread class wrapper built
>   on top of PThreads
>
> ... IO is next on my todo list of library adaptation :)
>
> -- 
> Do your users a favor: give them Style: http://www.uiwithstyle.org
>