Re: [java-gnome-hackers] Mixing generated and hand-written classes

[Colin W. <wa...@ve...>]

On Fri, Mar 21, 2008 at 10:52 AM, Andrew Cowie
<an...@op...> wrote:
> On Fri, 2008-03-21 at 01:52 -0400, Colin Walters wrote:
>  > What would happen at the build process is that we'd parse that Java
>  > file,
>
>  Trying to inject hand written code into generated code is the defining
>  nightmare that the Enterprise Java world saddled itself with, to their
>  sorrow. We've spent two years steering clear of it; indeed the entire
>  architecture was designed with avoiding that anti-pattern in mind.

What are the concrete issues you see?  The slide link doesn't say.
And I don't see how this approach is related to "Enterprise Java".
What are you talking about?  EJB2?

> Human written JavaDoc is not an option; it is the *entire* point.

Simply put, I think it is more important to have as much coverage as
possible, with a completely consistent and predictable mapping.  After
that base is achieved, then you can go back and add custom
documentation at any time.

Now admittedly, I come from the C GTK+ world originally, and I've been
hacking on the platform for probably 7 years now.  So my perspective
is biased towards that world; though in the last 2-3 years I've been
immersed in the Java world.  What is bad about the hand-coding
approach for me is that it's *impossible* for me to write a nontrivial
application in Java/GNOME as is.

For targeting people who are coming entirely from the Java world and
are new to the platform, nice JavaDoc is certainly going to help.  But
look at it this way, the current approach of hand-coding bindings is
still broken for them, because although they get a nicer subset of the
API, they're still going to run up against coverage and consistency
issues.

I'm really worried that this project is going back into completely
hand-coded, custom mode.  Here's an example I found from the archives:
http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1018
There is no metadata in the .defs file telling you that that's a
method which emits a signal.  So how would you do something like that?
 In the current architecture, you'd hand-code it into the class.  But
then what happens a year from now, when someone adds a new method in
GIO like that, and some Java-GNOME contributor forgets about this rule
and binds it without the "fire" prefix or whatever?  The system
becomes inconsistent and confusing to both "platform hackers" and
"Java people" alike.

> The C API documentation discusses C memory management issues which are meaningless to a Java developer using our library.

Most of the methods that discuss memory management are of the form
foo_free or the like, which we aren't going to be binding at all.
I'm taking a closer look at the PyGTK system now to figure out how
their documentation system works.