Re: New 'GObject' as base for GtkObject?

[Owen Taylor <otaylor redhat com>]

To start off, language wars are simply off-topic here. GTK+ will not be
rewritten in anything but C, so the fact that C++ or Java or Haskell
is better has nothing to do with gtk-devel.

Guillaume Laurent <glaurent@worldnet.fr> writes:

> "Sergio A. Kessler" <ser@perio.unlp.edu.ar> writes:
> 
> > Guillaume Laurent <glaurent@worldnet.fr> el día 08 Dec 1999 22:02:02 +0100, 
> > escribió:
> > 
> > >Do you really think the average programmer would use the Gtk+ OO
> > >system as easily as an OO language ?
> > 
> > maybe or maybe not,
> 
> Come on. Suppose you were working at McDonalds and had to say
> "sparkling water added with coca extracts and sugar" instead of
> "coke", because around you, for some reason, people don't know that
> word.
> 
> And of course, people won't drink much of it, because it's so damn
> cumbersome to order.
> 
> That's how the GtkObject feels like when you're used to C++ or Java.

I learned C++ (and object-oriented Perl) before I started programming
straight C extensively, so I'm not sure that OO-sugar is as addictive
as you say.

I do admit that I enjoy using the Python (or Perl) bindings to
GTK+ when I can just write

 container.add(button)

instead of:

 gtk_container_add (GTK_CONTAINER (container), button);

But, there are a lot of other issues involved in choosing a language
than the number of characters I have to type.

Also, admitttedly, GtkObject would be really cumbersome when used for
defining a fine-grained object heirarchy. I would not want to derive a
new GtkObject class for every dialog in my application. But this is
not how you use GTK+, and this is not the target application of
GtkObject. GtkObject might be better called a component-system 
than an object-system.

It adds many features that go beyond a simple object system. To name
a few:

 - The signal system
 - The argument system
 - Refcounting
 - Introspection including runtime queries of signals and arguments
 - run-time type identification
 - run time registration of new classes

If you created a C++ system to handle such objects, the amount of
work you need to do beyond straight C++ is not trivial. 
If I think of a few of the more complex C++ programs I've looked
at or worked on, they all have quite involved systems for doing
components and base objects:

 - Mozilla (XPCOM)
 - Qt (QtObject, moc compiler for signal/slot mechanism)
 - MICO (CORBA object system)

And in fact, none of these handles all of the features listed above.

When I write C, it is frequently quite object-oriented, but if I
don't need reusable components with notification, etc, then I am 
certainly not going to use GtkObject. I'll write things like:

 MainWindow *
 main_window_new (const char *title)
 {
   MainWindow *result = g_new (MainWindow, 1);
   result->title = g_strdup (title);
   result->window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

   return result;
 }

 void
 main_window_destroy (MainWindow *window)
 {
   g_free (window->title);
   if (window->window)
     gtk_widget_destroy (window->window);

   g_free (window);
 }

Or whatever. This will definitely be more typing than Python, and 
a bit more typing than C++, but it isn't nearly as painful as
you make out. 

GtkObject is not C++ done with macros, it is a component system that
extends the simple (and quite traditional) methods of doing 
programming with "objects" in C. 

If your programming style involves lots of fine-grained objects, you
almost certainly do want to use a "real" OO language of some sort, but
there is plenty of code that can be done in a readable, maintainable,
and even convenient fashion using GtkObject and C.
 
> > but then this average programmer could use the bindings of gnome,
> > gtk for an OO languaje (wich are easy to do/possible thanks to the C
> > languaje).
> 
> Yes, but no. This has been discussed before.
> 
> - These bindings are not always easy to do, and sometimes they are
>   pretty damn difficult.

Suggestions as to how to make GTK+ better at creating bindings are
very much on topic here. Actually, I think GTK+ is very easy to start
for people to get 90% of the binding, but we do have some problems with
completeness and maintainability.
 
> - Bindings have their own share of drawbacks anyway.

Well:

 - The set of languages that are suitable for writing a toolkit
   in is much smaller than the set of interesting languages.

 - The amount of work to create a good toolkit is very, very large.

So, it is clear that bindings of language X to toolkit Y are useful
and important.

>From my personal experience, the Perl and Python bindings are very
nice, very easy to program in, and quite well maintained. The GTK+
bindings also serve quite an important role for a lot of "small-scale"
languages that don't have standard or native toolkits, even if the
bindings to those languages aren't 100% complete.

Java and C++ are the languages where a GTK+ binding is perhaps not so
clearly a win - Java has standard toolkit APIs in AWT and Swing, with Swing
(assuming performance) being quite nice. C++ has a large community of developers
and there are a number of actively developed native C++
toolkits. Assuming equal quality, and equal conformance to the 
platform look-and-feel, a native toolkit will be clearly
preferable to a bound one. 

But that does not meant that language bindings are a bad idea.
In general, I'd consider them a good thing. It is better to 
have one or two well-done toolkits than 10-15 half-baked toolkits.

Regards,
                                        Owen