[Java-gnome-developer] I couldn't help myself

[Dan B. <da...@mi...>]

I went ahead and implemented the passing of arguments of enumerated types
as I outlined. I think this made the C compile get a lot cleaner, in that
I'm getting much fewer warnings of the form:

    glue/gnome_GnomeFontPicker.c: In function `Java_gnome_GnomeFontPicker_setMode':
    glue/gnome_GnomeFontPicker.c:123: warning: passing arg 2 makes pointer from integer without a cast
    glue/gnome_GnomeFontPicker.c:125: warning: passing arg 2 makes pointer from integer without a cast

My changes ended up exposing another preexisting problem, though, which is
almost certainly the cause of some (potential) crashes. Namely, the
generator cannot deal at all with pointer-to-enum. I found one place where
an attempt was made to define such a function (gnome_doc_get_item_by_name).
I didn't look too hard, so I could've missed a bunch, for all I know. With
my version, this particular example failed to compile entirely (because the
type was specified as an enum, not as a pointer to enum--gcc merely warns
for implicit int-to-pointer conversions but will issue an error for
implicit enum-to-pointer). After fixing the type declaration, I found that
the generator doesn't really distinguish "enum type" from "array of enum
type" very well. I commented the one place in gnome.defs where this
mattered, and left it at that for now.

My thoughts on the matter are this:

* In the case I found, the only reason for using a pointer was to get
  multiple return values from a method. It may make sense to have a more
  general mechanism for specifying output arguments, rather than relying on
  C semantics, and attempting to reproduce those semantics in Java. For
  example, we might want to automatically declare a "return value from
  method x" class for each method that does this sort of thing, and then,
  on the Java side, have such an object passed in as a "secret parameter".

* If there's a need, we also might want to bite the bullet and define
  classes that represent arrays of enumerated types. Such objects would
  really just hold an internal int[], and this would be what is passed in
  to the native method, via a similar unwrapping mechanism to how simple
  enumerated types now work. The Java interface to the object, though,
  would always intern the ints into the appropriate class on the way out.

On a final note: While I did get everything working, I'm not totally happy
with the structure of the code. In particular, I ended up doing type
reasoning in MethodDefinition in a couple places, which probably would be
better done in TypeDefinition. (I didn't quite understand how the classes
were interacting at first, and so I tended to try to make my changes in a
minimally intrusive way.) Basically, there probably ought to be a method in
TypeDefinition that returns the Java type corresponding to the JNIType (I
called it the "unwrapped type" below). Here's an example:

    Java type:            "GtkCellType"
    Java unwrapped type:  "/* GtkCellType */ int"
    JNI type:             "/* GtkCellType */ jint"
    Native type:          "GtkCellType"

The thing that's missing is a method which returns the unwrapped type. The
thing that figures that out is hard-coded into MethodDefinition in a couple
of places.

Anyway, since I don't have time to do anything more significant this
weekend (and my place d'emploi probably wouldn't like it if I spent my day
working on Java-Gnome), I figured that I'd leave things alone for now, but
that someone else or I could refactor the code later. I left "FIXME"s in
the code in the couple of places where it matters.

I've created patches both against the original sources and against my
update from yesterday. I'll put them on sourceforge, but they're also here:

  Full diffs from the cvs repository:
    <http://condensed.milk.com/~danfuzz/java-gnome/full-diffs.txt>

  Just the diffs from today's work:
    <http://condensed.milk.com/~danfuzz/java-gnome/enum-diffs.txt>

Take care, and hope everyone's weekend was a good one,

-dan