Thomas Fitzsimmons wrote:
Sven de Marothy wrote:
On Mon, 2006-05-22 at 22:53 +0200, Robert Schuster wrote:
The way its done now is pretty simple and there is much room for
enhancement.
However I want to have some feedback on the current state because I
am new to
Gdk/Gtk+ and Xlib/XRandR programming and had to work myself into the
goodness of
Classpath' "Magical NSA API" ... ;)
I'm not sure we should use the NSA stuff for new code. I personally
don't think it's a very good solution. It obfuscates where the actual
data is at behind an undocumented and unintuitive set of macros. It also
makes it harder to see what native data structures the java classes map
to. It's one of the things that makes understanding and working on the
Gtk peers more difficult. The Pointer/Pointer32/Pointer64 classes also
do their job in contributing.
Storing the native pointer as a simple long field works just fine on any
platform. I don't see the point of not Keeping It Simple.
Agreed, and I think we should replace existing NSA code with the simpler
long field approach. Ideally we could remove the NSA implementation
altogether. I'd also like to see Pointer/Pointer32/Pointer64 gone but
they seem to be used in places other than the peers.
I should have said: Robert: go ahead and commit your NSA-using patch when it's
ready -- I don't want to delay it. After it's committed we can look at
replacing all NSA code in one big patch.
Tom
