Re: New 'GObject' as base for GtkObject?

[Guillaume Laurent <glaurent worldnet fr>]

Tim Janik <timj@gtk.org> writes:

> this may sound overly complex and undoable, but the reuqired knowledge is
> already there in the minds of language binding, gdome, gtk+, libsigc++ etc...
> project maintainers. it's just ;) a matter of this bunch of people getting
> their guts together and come up with a profound design.

Actually, that's only one half of the problem. Gtk-- has to bend over
backwards to accomodate the gtk+ OO system, mostly the signals because
of the lack of consistency (is it a signal, a "virtual function", can
the user emit it or not, etc...), but once it has done that, it has to 
put spilled toothpaste back into tubes.

The other big half is that this OO system is *very* tedious to
use. It's not part of the language, it's a syntactic
convention. Therefore, a coder will use it only when literally forced
to, but fall back to plain old structures and other C-isms at the drop
of a hat. So we get things like GtkItemFactoryEntry, GnomeUIInfo,
etc...  (disregarding the fact that all these, and a few others too,
assume that a callback can be a function ptr and nothing else).

And no matter which OO system you can devise, you will always have
these problems.

It's just like trying to do structured programming in assembly,
manually following the calling conventions of a function, the loops,
etc... It's asking the programmer to do the job of the compiler. It
can be done, but it doesn't scale.

-- 
					Guillaume.
					http://www.worldnet.fr/~glaurent