Re: Fwd: GTK+ is real object oriented?

[Michael Torrie <torriem gmail com>]

frederico schardong wrote:
> Yes, C don't provide sintax support for do my example of method.

Syntactical support is not required for an object-oriented system; it
merely makes it easier for you, the programmer.

> In OOP such class must have self methods to set self attributes.

Yes, and gobject certainly has this.

> What happen is GObject (by the C limitation) just have attributes, the
> methods to set its attributes are functions out of the struct. Ok, is
> this what happen, but for this facts don't broke the OOP?

No, GObject has both attributes and methods.  Just like in C++, there is
a struct to hold the data members (the attributes) and a call table to
hold the methods.  This is why you can call a GtkWidget method on an
instance that is a descendant of GtkWidget and it still works.  For
example, a button:

b=gtk_button_new()
gtk_widget_show(b)

The "show" method of the GtkWidget class can be called on the instance b
because it descends from GtkWidget, even though it is of the GtkButton
class.  Even more convincingly, if I overrode the "show" method in my
own GtkWidget-derived class, a call to gtk_widget_show(myinstance) would
call my own classes show because show is a virtual method.  So the call
table tells the compiler which method to actually call.  Pretty much
like C++, except that it's not hidden as cleanly.

Note that there is absolutely no functional difference between using
this class/method/instance combination for a method call from the
instance/method idea.  In other words:

gtk_widget_show(instance)

is identical to

instance.show()

The only difference is one of convention.  Don't get hung up on where
the "." or "->" is.  One might be preferred over the other by you, but
that does not mean that GTK is not object-oriented.  If you don't like
the C syntax used to constuct, destroy, and call methods on an object,
then I suggest you use GTKmm with C++, Vala, or PyGTK.  In each case the
Gobject system is accessed via the native object-oriented conventions.
Since GObject OO, the bindings are really just thin wrappers to thunk
from one object system to another.