Why Was the GObject System Created? [closed]

Question

The Introduction

Okay, so after version 0.60 of GTK+, the designers realized that for future development and progress, the entire toolkit needed to be rewritten to be object-oriented.

Now, since C doesn't support OOP, to provide object-orientation and in inheritance heiriearchies, they created the GObject System. Now creating the GObject System must have required development time, more dependencies, more problems, but they had to create it to provide object orientation capabilities to the C Programming Language. But at that time, there was another solution that provided exactly that, C++!

The Question

Why didn't the developers of GTK+ just use C++?

The Explanation

I mean, Why waste time creating an entire library instead of using a time-tested solution adopted by a lot of projects? Don't get me wrong, I am not trying to turn this post into a C vs C++ thing (I've had enough of that on forums, thank you). I just want to know the reasons and issues that made the designers of GTK+ make the decision they did.

Wooton

@HansPassant the project could still have been extended with C++. As C++ is compatible with C. – Wooton

@IntermediateHacker: For the most part, C programs can be treated as C++ programs. But this is not a strict relationship, since certain C notions (e.g. restrict) do not exist in C++. – Jenijenica

C++ is not "exactly" C with "object orientation capabilities" – Eisenhower

GTK was not re-written primarily for addition of object-oriented features... look at the answer with Wiki quote... – Horologium

Answer 1

I can't directly answer the question, at least as far as GTK goes. That answer lies with the GTK+ developers, so you'll have to hunt them down and ask them. But as for why one would want to add an object oriented system to C, instead of using C++, there are plenty of reasons. The three I would immediately think of are

1. Language Complexity: While C is a pretty simple language, C++ is mind-numbingly complicated, with support for most (not all) C stuff, as well as conveniences like references, and also object-oriented features and a complex template language. And have you seen the new system of values: lvalues, rvalues, glvalues, prvalues and xvalues - huh? There's plenty more I could talk about. Given time, C++ becomes manageable, but it's still overkill for just wanting some object oriented features in C.

2. Control: If the designers went with C++, they'd be stuck with C++ philosophy. For instance, multiple inheritance is a controversial idea, and for good reason. By design, the GObject system is built to only support single inheritance, which can drastically simplify the inheritance hierarchies. If the designers went with C++, there would be no way to limit users to a single inheritance system. Multiple inheritance is just an example - I'm sure there's plenty of other places in which the GObject system differs from the C++ ideology.

3. Interoperability: This is probably a big one. Although there a few languages with which C++ interoperates cleanly, the fact is that C++ just isn't that great at interop. However, interoperability with C is almost taken for granted. C is often described as the lingua franca of programming languages, since it forms the de facto standard for interop. By designing a C API, the GObject designers opened the door to GTK+ development in any number of languages.

Jenijenica

@NicolBolas The answer represent possible line of thought of or choices faced by GTK developers before they developed GTK. Like the answerer mentions, the answer lies with the GTK+ developers. – Horologium

I believe #3 was particularly attractive. Bindings for C++ can be done, but the situation have always been slightly better for C. – Gant

@NicolBolas: Either answer the question or don't, but your snide comments aren't helping anyone. – Eisenhower

The simple answer : C++ does NOT define an ABI ( application binary interface ) whereas C does. Hence, C based GObject. Microsoft built COM for the same reason. – Gastelum

While C is a pretty simple language, C++ is mind-numbingly complicated GObject is much harder than C++ (I know and use both) simply because its type system isn't statically checked, and you have to use oodles more boilerplate. Anyway, it may as well be its own language (it has its own garbage collection and OOP semantics--it is an object system after all)--most common plain-C libraries have a gobject library for which bindings are manually maintained. – Dixiedixieland

For instance, multiple inheritance is a controversial idea, and for good reason. By design, the GObject system is built to only support single inheritance, which can drastically simplify the inheritance hierarchies. Also a bunk reason; why would they care if users use MI or not? It wouldn't affect their project (GIMP) and there's nothing about C++ that forces you to use MI. Just don't do it if you don't like it (that's my philosophy, and I've never run into problems). – Dixiedixieland

Interoperability C++ can be externed to C. Check out libclang for a really good example. These three comments are why I -1'd this answer. It's one of the most highly voted, accepted, misinformative answers I've seen on SO. – Dixiedixieland

@Dixiedixieland "might as well be its own language" - I'm not sure, but I'm pretty sure that's called Vala :) In any case, that's a fair point. – Jenijenica

@KenWayneVanderLinde I know Vala and use it once in a while when I get frustrated with plain GObject. Then I get frustrated with Vala and go back to plain GObject. Sometimes I get frustrated with both and revert to Qt. Then I get frustrated with Qt's meta-object/black-magic type system and go back to GObject... :( – Dixiedixieland

@Dixiedixieland About MI: The reason a designer cares about whether users will use MI or not is that MI requires extra design effort since there do exist real problems with it, even though the common use cases may not have such problems. In other words, implementing MI may not be worthwhile. – Jenijenica

@KenWayneVanderLinde I understand that MI takes additional work to implement, but if it's already been implemented by someone else (as in the case of C++) then I can't see any reason why the GIMP folks would care. – Dixiedixieland

@Gant What's the problem with binding the C++ to C and then binding the other language to C? As I understand it, binding from C++ to C is relatively easy. – Dixiedixieland

@Dixiedixieland Replace C++ with "language of your choice" and all these same arguments can be made. But if we're going to make C bindings anyways, why bother? At the end, it boils down to a choice, not a technical restriction. – Jenijenica

@KenWayneVanderLinde It's easier to write C bindings for C++ libs than for many other languages AFAICT. At the end, it boils down to a choice, not a technical restriction <- One hopes technical concerns are factored into decisions, but remember: we're talking about why the choice may have been made. Perhaps the decision to write the GObject system did derive from the points you outlined above, but I want to clearly highlight that those points are mostly misinformation. :S – Dixiedixieland

@Gastelum to be pedantic, you mean C++ has various ABIs but not yet a standardised ABI that would guarantee interoptability between compilers on a single architecture - and I say yet because they are working on it, e.g. this by Sutter: isocpp.org/files/papers/n4028.pdf – Anaclinal

@Anaclinal yes, i've been tracking that too, but its a long road before there is a critical mass of compilers, OSes and basic libraries onboard. Once there is an actual OS kernel built on top of extern "abi" ( and its not called Symbian ;) ) victory can be claimed. – Gastelum

Answer 2

GObjects is intended to be language independent. It has dynamic typing, and you should it compare with a run-time system like COM, .NET or CORBA, rather than with specific languages. If you go into languages, then the features are more at the Objective-C than the C++ side.

Unsegregated

Answer 3

The GObject type system does things that you can't do in C++. For one thing, it allows creation of new classes at runtime, and does this in a way that is language-independent - you can define a new class in Python at runtime, then manipulate instances of that class within a function written in C, which need not even be aware that Python was ever involved.

Wares

Pedantic, perhaps, but it can be done in C++. You mean that it isn't built-in to C++, with regards to run-time class creation. – Swimming

I don't think I've ever needed to dynamically create a class. Genuinely curious--are there any real use cases for this? If so, what are some examples? – Dixiedixieland

@Dixiedixieland I've used run-time class creation in library bindings. You can walk a library API at runtime and make a GObject class (and therefore a GObject API) for each main feature. – Exmoor

@user894763 which enables you to do what, exactly? – Dixiedixieland

@Dixiedixieland Use that library from any language with a GObject binding. – Exmoor

@user894763 Perhaps I'm still misunderstanding, but that seems a bit circular. My question was effectively, "Why would you need to dynamically create a class?" and your answer was effectively, "To dynamically create classes". Can you elaborate a little more on why someone might want to dynamically create classes? Why is this a useful feature? – Dixiedixieland

Sorry I'm not being very clear. Suppose you have libfoo, a library not based on GObject, and you'd like to use it from a language like JavaScript, which has a mature GObject interface. One way to do this is to write a tiny bit of C to introspect libfoo and (at runtime) generate a set of GObject classes, one for each feature you'd like to use. Now you can call libfoo from JS. The advantage here would be that the binding is made at runtime and so will automatically update as features are added to libfoo. Of course there are many ways to make library bindings, but this can be useful in some cases – Exmoor

@user894763 Nice idea, but it sounds easier said than done ;-) Can you provide some examples of where this has practically been achieved? – Anaclinal

@underscore_d, here's an example from one of my projects. I maintain a GObject-based image processing library: github.com/jcupitt/libvips You can use it from at least Ruby, Python and JavaScript via those languages GObject bindings. The previous version of vips was not GObject-based, so you can't use operations from the old API ... except there's a thing to walk the old introspection system and generate GObject classes, so you can! github.com/jcupitt/libvips/blob/… – Exmoor

Answer 4

From the wiki linked to in the question:

History (From Wikipedia)

GTK+ was originally designed and used in the GNU Image Manipulation Program (GIMP) as a replacement of the Motif toolkit; at some point Peter Mattis became disenchanted with Motif and began to write his own GUI toolkit called the GIMP toolkit and had successfully replaced Motif by the 0.60 release of GIMP.[3] Finally GTK was re-written to be object oriented and was renamed GTK+. This was first used in the 0.99 release of GIMP.

---

This should tell you that object-oriented paradigm was not a paramount criterion for the choice of language for GTK (which is different from GTK+) and that feature was added much later.

Horologium

I still don't understand why anyone would inflict that kind of pain upon themselves. C++ isn't great, but it sucks infinitely less than GObject. :( – Dixiedixieland

...What made you think this was an answer? The question is why it was re-written in C, instead of C++ or some other natively OOP language. Just telling us that "it was re-written" is a total tautology. I guess we're meant to infer that it wasn't a total rewrite and/or the core team had preferences for C - for reasons supposed in better answers. – Anaclinal

This is a good answer. The GIMP is a C project. GTK (and GTK+) was initially written to be a GUI toolkit for The GIMP, so C was a natural choice for a C project's library. GObject was extracted from GTK+, and retained the C heritage. It's still C because the entire heritage was C, and it was originally extracted from a C library for a C program. At no point in the history did another language make much sense for this purpose. If it was written initially from the ground up to be an object system, it might have been different, but its history wasn't that kind of project. – Stidham

It's called GIMP, not The GIMP. The Gimp is a fictional character in a Quentin Tarantino movie. – Gentility