+Also note that this structure is dynamically allocated, and is freed in the
+finalize handler. If you override the finalized handler, your code will be
+run first and only then will the _priv structure be freed.
+.PP
+Classwide data members:
+.PP
+Sometimes you want a datamember to be shared by all objects. You then need
+the "classwide" scope keyword. So for example the following adds a global
+member foo:
+.nf
+
+ classwide int foo;
+
+.fi
+To access the member you do the standard voodoo of getting the class from the
+object and casting it to your class pointer. Thus the following would work:
+.nf
+
+ SELF_CLASS(GTK_OBJECT(object)->klass)->foo = 20;
+
+.fi
+.PP
+Automatic Initialization (0.93.0 and higher only):
+.PP
+You can automatically initialize the public private and protected data members
+without having to add an init method. The advantage here is that
+initialization is kept close to the definition of the data member and thus
+it's easier to check. To do this, just add a '=' followed by a number or
+a token. It is also possible to include arbitrary C code for more elaborate
+initializations by putting it all in curly braces. Note that the curly braces
+will not be printed into the output, but since gob does not C parsing it needs
+them to figure out where the C code ends. The code will be inserted into the
+init method, above the user defined body. So for example the following
+will initialize an integer to -1 and a string with a newly allocated string
+of "hello".
+.nf
+
+ public int foo = -1;
+ private char *bar = {g_strdup("hello")};
+
+.fi
+.PP
+Automatic Destruction (0.93.0 and higher only):
+.PP
+Most data stored as pointers needs to have a function called when the object
+is destroyed, to either free it or give up a reference. Gob will let you
+define a function to be called on the data the object is destroyed. This is
+achieved by putting 'destroywith' followed by a function name after the
+variable definition. It is only called if the data you defined this on
+is not NULL, so you cans specify functions which do not handle NULL. It
+is very much like the GDestroyNotify function used in GTK+ and glib in many
+places. Unlike many other places, gob will not enforce any kind of type
+safety here so be a little bit more careful. Any function you give it will
+be called as a "void function(void *)". It will in fact be cast into such
+a form before called. This is to avoid spurious warnings for gtk calls to
+subclass methods. The function needs not be of that form exactly, it just has
+to take one argument which is the pointer to the data. You should also not
+define this on any non-pointer data as the results may be undefined.
+Example:
+.nf
+
+ public Gtk:Widget *window = NULL
+ destroywith gtk_widget_destroy;
+ public char *foo = {g_strdup("bar")}
+ destroywith g_free;
+
+.fi
+Note that the function name you give must be a real function and not macro.
+Also note that this is always called in the "destroy" method of GtkObject.
+It is always called after any user defined body of the destroy handler.
+.PP
+Sometimes you may want to run arbitrary code on destruction. While this can
+be perfectly well done in the destroy handler. Depending on the style you
+may want to include all destruction/initialization code together with the
+definition of the data member. Thus you may want to put arbitrary code which
+will then be inserted into the "destroy" method of GtkObject. This can be
+done with the "destroy" keyword followed by arbitrary code in curly braces.
+Inside this code a macro called VAR will be define which refers to your
+variable. So for example destroying a GString can be either done with
+a helper routine or the following code:
+.nf
+
+ public GString *string = {g_string_new(NULL)}
+ destroy {
+ if(VAR) g_string_free(VAR, TRUE);
+ };
+
+.fi
+The thing to remember with these is that there are many ways to do this
+and you'd better be consistent in your code in how you use the above things.
+Also defining a helper routine that will do the destruction will be a nicer
+thing to do if that's a possibility. The "destroy" keyword with code does
+take up more space in the file and it may become more cluttered.
+.PP
+The data is zeroed out after being destroyed. This is to make debugging easier
+in case your code might try to access an already destroyed object. In case
+you have overridden the destroy method, your code will be run first and
+only then will the destructors be called. You should not however make any
+assumptions about the order at which the destructors are called. If you have
+interdependencies between destructors for different data members, you will
+have to do this in your own destroy override function.
+.PP
+GTK+ Arguments:
+.PP
+The fourth type of a data member an argument type. It is a named data member
+which is one of the features of the GTK+ object system. You need to define a
+get and a set handler. They are fragments of C code that will be used to get
+the value or set the value of the argument. Inside them you can use the define
+ARG to which you assign the data or get the data. You can also use the
+identifier "self" as pointer to the object instance. The type is defined as
+one of the gtk type enums, but without the GTK_TYPE_ prefix. For example: