9 Apr 2001 (updated 9 Apr 2001 at 01:57 UTC)
»
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]