[java-gnome-hackers] API proposal: remove GObject(int) and GObject.addEventHandler(*)

[Tom B. <Tom...@Su...>]

In the grand software tradition of "ready, fire, aim", I'd like to
remove some API calls that I just checked in lots of references to.  You
can see why I'm a big fan of refactoring!

Back when I first volunteered, Jeffrey said that he wanted to move
everything over to his new event handling architecture and away from the
use of GObject.addEventHandler().  With the EventMap code checked in,
the only remaining references outside of org.gnu.glib of addEventHandler
are in org.gnu.gnome, and I will eliminate them shortly.  Once that's
done, the addEventHandler methods can be made package-private to
org.gnu.glib.

I'd like to go a bit further and eliminate all the public constructors
that take an existing native handle (including the ones added to support
the above change).  These calls aren't typesafe, because they assume
that the caller knows the correct type of the handle, allowing for
strange and hard to debug errors later in the program's execution if the
GTK class doesn't match the Java-GNOME one.

What I'd like to use instead is a static factory method,
GObject.makeObject(int) (anyone have a better name?).  This method would
use gtk_type_name to get the actual class of the object, then create a
new Java-GNOME instance of that class and directly stuff the handle into
the object before returning it.  Client code that used to do this:

    Button btn = new Button(handle);

would be:

    Button btn = (Button)GObject.makeObject(handle);

In general, only Glade would actually do this.

org_gnu_glade_LibGlade.c has code to map the GTK class name to our own,
but that logic belongs somewhere like GObject since it can be broken if
we don't follow its hidden assumptions.  A simple GTK->Java-GNOME class
map would be much easier to maintain, and can aid documentation as well.

Comments?

Tom