Re: [java-gnome-hackers] a possible merge strategy

[Stefan P. <st...@pr...>]

Hi Colin,

your approach of generating the API is definetly interesting. As you
might be aware we are also having autogenerated code in java-gnome (from
the .def-files), so although the way it is done is different a common
idea exists.

What is different is our philosophy. We decided for a reason not to use
the generated API as a public API, since often the usage of the
generated APIs is not what a normal Java programmer usually would do.
So we have this handcrafted public API to smoothen the edges of
underlying APIs and reduce the learning curve for developers coming from
the Java world.

A good example for that you gave yourself:
> TextIter iter = new TextIter();
> buf.getStartIter(iter);

A more Java-like approach would be
  TextIter iter = buf.getStartIter();

> Now,
> arguably this could be an <out> parameter, and getStartIter() could
> return it, but the current structure binding generalizes to multiple
> arguments well enough.  I might later do an optimization around this
> case, we'll see.

This is a question of philosophy. We prefer to make those optimizations 
before making an API public.

> The big picture here is that ideally, we can merge efforts and have
> the best of both worlds - an autogenerated complete API useful to
> platform hackers like me, and hand written custom bindings for tricky
> things like GtkTreeView on top, and share binding code for things like
> Cairo which aren't covered by introspection.

Personally I would like to keep the hand written API, because I see it
as a big plus. 

> But the first fundamental piece that would need to be merged is the
> GObject mapping layers.  In JGIR, GObject.java is actually written
> entirely in Java, using JNA.  You can see this code here:
> http://svn.gnome.org/svn/java-gobject-introspection/trunk/src/org/gnome/gir/gobject/GObject.java
> To merge this we'll have to figure out also how the Cairo library
> plugs in.  Should be relatively straightforward.

Another possibility would be to use JGIR to feed our code generator and
replace our .def files. By that we would get a much better non-public
binding to write the public binding for.
This might go together with improvements on our GObject code, but that
must be discussed with people more familiar with the ugly binding
details than me.

> And for the custom classes, it should be relatively straightforward to
> just rebase their internals on the JGIR if we can do the first part
> right.

JGIR is definetly an interesting aproach and it would be nice to have
you onboard helping us with our code generation. You seem to have put a
lot of effort on this, so it would be a shame if we could not both
benefit from this. But I would not go so far to rely on automated
generated public APIs using JGIR.

Regards,
  Stefan