Editing GObject (section)

===Derived types===
The types that are derived from the built-in GObject fundamental types fall
roughly into four categories:
; Enumerated types and “flags” types : In general, every enumerated type and every integer-based bitfield type (i.e., every <code>enum</code> type) that one wishes to use in some way that is related to the object system &mdash; for example, as the type of an object property &mdash; should be registered with the type system. Typically, the initialization code that takes care of registering these types is generated by an automated tool called <code>glib-mkenums</code><ref>{{cite web|url=https://developer.gnome.org/gobject/stable/glib-mkenums.html|title=glib-mkenums, GObject Reference Manual}}</ref> and stored in a separate file.
; Boxed types : Some data structures that are too simple to be made full-fledged class types (with all the overhead incurred) may still need to be registered with the type system. For example, we might have a class to which we want to add a <code>background-color</code> property, whose values should be instances of a structure that looks like {{code|2=c|1=struct color { int r, g, b; } }}. To avoid having to subclass <code>GObject</code>, we can create a [[boxed type]] to represent this structure, and provide functions for copying and freeing. GObject ships with a handful of boxed types wrapping simple GLib data types. Another use for boxed types is as a way to wrap foreign objects in a tagged container that the type system can identify and will know how to copy and free.
; Opaque pointer types : Sometimes, for objects that need to be neither copied or reference-counted nor freed, even a boxed type would be [[Overkill (term)|overkill]]. While such objects can be used in GObject by simply treating them as opaque pointers (<code>G_TYPE_POINTER</code>), it is often a good idea to create a derived pointer type, documenting the fact that the pointers should reference a particular kind of object, even though nothing else is said about it.
; Class and interface types : Most types in a GObject application will be classes &mdash; in the normal object-oriented sense of the word &mdash; derived directly or indirectly from the root class, <code>GObject</code>. There are also interfaces, which, unlike classic [[Java (programming language)|Java]]-style [[interface (object-oriented programming)|interfaces]], can contain implemented methods. GObject interfaces can thus be described as [[mixin]]s.