9 Apr 2001 dto   » (Journeyer)

Recent thoughts and a suggestion; to be taken with a grain of salt.

The new GObject standard implements a dynamic object system and runtime library on top of ANSI C. From what I can gather, this is an extension of and "factoring out" of the original GTK+ object/type system.

I've done a fair amount of GTK+ coding in C, and my current (+1 year) project has involved heavy use of object-like conventions applied to the C language. (I am developing a free music system as part of the GNU Project.) I like this stuff. I make no pretensions to caring whether or not a language is "purely" object-oriented, or even whether it is object-oriented at all.

What I do care about is convenience and clarity in programming. There are several big "costs" associated with using GTK+ and similar styles of implementing objects in C:

  • Constantly having to dereference yourself in your own objects: self->foo, self->bar. This alone can make a 10-15 line member function look extremely dense.
  • Long method names. There is just one big namespace, so the name of the class is prefixed to every single method name, every time it is called. Even worse, you have to explicitly call gtk_superclass_operation(foo) even if foo is more specialized. That is, you have to remember which classes the methods are originally declared in when calling, instead of just invoking them on the object.
  • Constant need for casting macros like GTK_ADJUSTMENT(foo), GTK_CONTAINER(foo) and the like. This is made worse by the fact that typically you only use them inside argument lists of calls (i.e. nesting gets ugly.) Unless you declare extra pointers with the right type and cast them earlier on, you have to do this or get compiler problems and risk type errors. Even that is extra lines of code using cast macros; there's no way for clarity to win on this one.

GTK+ and its object system are still easy to use and relatively straightforward. I think it is an excellent user-interface library. But if there is one real criticism to be made of GTK use, it is this: at times the sheer verbosity of the object system makes GTK client code compete head-on with some of the densest Java. In my own programs, at times I feel the benefits I get from using abstract data types and "interfaces" are almost completely canceled out by the amount of time I have to spend typing these macros and class names over and over again and making sure everything matches up.

(For several reasons, I cannot use Glade to speed this up for me.)

Languages are a touchy issue---I hope nobody will take this the wrong way. I make no criticisms of the design of anyone's library or object system. My concerns here are limited strictly to usability at the syntactic level, and are based entirely on my own experiences.

Here is my suggestion for improving the situation. Provide a runtime dynamic object library just as is planned with GObject, but also provide a minimal set of syntax extensions on top of C, so that all three problems mentioned above just disappear.

No time to design and build something new, you say? But someone has already built a small syntax extension to C that fits the above requirements exactly. What's more, the neccessary tools for using this set of extensions are already included with every copy of the GNU C Compiler. This extension is called Objective-C, and it is the native language of both GNU's GNUstep project and Apple Computer's new Cocoa framework for developing OSX applications. The language is currently moving toward standardization using C99 as a base.

The main changes are few and are quickly learned: interface and implementation keywords, as well as a somewhat odd (but very readable) syntax for message passing: [reciever message:arg]. There are other wrinkles, but overall it adds up to a set of extensions that complement C's abilities and provide conveniences, rather than (like C++ does) obsoleting large chunks of the language and providing numerous pitfalls.

I would like to propose that app developers for GNOME and GTK start investigating this. Everything that I have learned so far tells me that Objective-C is exactly the "small step" that I, and possibly others in the world of UNIX applications development, would like to take. I don't want to give up even one bit of C's power, but I'm not afraid of convenience and new tools. I like to use abstract data types and some interfaces, but I don't want a completely new language that throws out what I know. Only the parts you want to write in objc need be written that way---the language is completely compatible with C. There are already objc bindings for GTK+ and GNOME, but they do not appear to be actively maintained. Generating interest in the language and volunteering help (as I am doing) could change the situation and find a real answer to the agonized "C or C++" question for people interested in trying something new.

With reference to GObject, in the immediate future, I believe that we could explore two possibilities:

  • Improve the existing Objective-C bindings for GTK+ and GNOME and keep them up-to-date, so that people can begin developing more applications, and so that the barrier to experimentation for other developers is lower. I am willing to help with the bindings, so I have contacted the people involved.
  • Either that, or somehow make GNU Objective-C compatible with GObject (such that it would use GObject transparently as its runtime library.) I have no idea whether or not this is possible, but it would be great because Obj-C would then simply be "extra syntax support for GObject", and we'd have the happy side-effect of not having to make a new dialect ourselves.

Someone with better knowledge of GObject's design would have to comment on these ideas. Thank you, if you have read this far into my rant :-).

-dave

[link to more info on objective c]
[Apple's recent book on Objective-C]

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!