Editing GObject (section)

==The type system==
At the most basic level of the GObject framework lies a generic and dynamic [[type system]] called GType. The GType system holds a runtime description of all objects allowing [[glue code]] to facilitate multiple language bindings. The type system can handle any [[single inheritance|singly inherited]] class structure, in addition to ''non-classed'' types such as [[opaque pointer]]s, [[string (computer science)|strings]], and variously sized [[integer]]s and [[floating point number]]s.

The type system knows how to copy, assign, and destroy values belonging to any of the registered types. This is trivial for types like integers, but many complex objects are [[reference counting|reference-counted]], while some are complex but not reference-counted. When the type system “copies” a reference-counted object, it will typically just increase its reference count, whereas when copying a complex, non-reference-counted object (such as a string), it will typically create an actual copy by [[memory allocation|allocating memory]].

This basic functionality is used for implementing <code>GValue</code>, a type of generic container that can hold values of any type known by the type system. Such containers are particularly useful when interacting with dynamically typed language environments in which all native values reside in such [[tagged union|type-tagged]] containers.

===Fundamental types===
Types that do not have any associated [[class (programming)|class]]es are called ''non-classed''. These types, together with all types that correspond to some form of [[root class]], are known as ''fundamental types'': the types from which all other types are derived. These make up a relatively closed set, but although the average user is not expected to create their own fundamental types, the possibility does exist and has been exploited to create custom [[class hierarchy|class hierarchies]] &mdash; i.e., class hierarchies not based on the <code>GObject</code> class.

As of GLib 2.9.2,<ref>{{cite web|url=https://developer.gnome.org/gobject/stable|title=GObject Reference Manual - Stable}}</ref> the ''non-classed'' built-in fundamental types are:
* an empty type, corresponding to C's <code>void</code> (<code>G_TYPE_NONE</code>);
* types corresponding to C's signed and unsigned <code>char</code>, <code>int</code>, <code>long</code>, and 64-bit integers (<code>G_TYPE_CHAR</code>, <code>G_TYPE_UCHAR</code>, <code>G_TYPE_INT</code>, <code>G_TYPE_UINT</code>, <code>G_TYPE_LONG</code>, <code>G_TYPE_ULONG</code>, <code>G_TYPE_INT64</code>, and <code>G_TYPE_UINT64</code>);
* a Boolean type (<code>G_TYPE_BOOLEAN</code>);
* an enumeration type and a “flags” type, both corresponding to C's <code>enum</code> type, but differing in that the latter is only used for [[bit field]]s (<code>G_TYPE_ENUM</code> and <code>G_TYPE_FLAGS</code>);
* types for single- and double-precision [[IEEE float]]s, corresponding to C's <code>float</code> and <code>double</code> (<code>G_TYPE_FLOAT</code> and <code>G_TYPE_DOUBLE</code>);
* a string type, corresponding to C's <code>char *</code> (<code>G_TYPE_STRING</code>);
* an opaque pointer type, corresponding to C's <code>void *</code> (<code>G_TYPE_POINTER</code>).

The ''classed'' built-in fundamental types are:
* a base class type for instances of <code>GObject</code>, the root of the standard class inheritance tree (<code>G_TYPE_OBJECT</code>)
* a base interface type, analogous to the base class type but representing the root of the standard ''interface'' inheritance tree (<code>G_TYPE_INTERFACE</code>)
* a type for [[Boxed type|boxed]] structures, which are used to wrap simple value objects or foreign objects in reference-counted “boxes” (<code>G_TYPE_BOXED</code>)
* a type for “parameter specification objects,” which are used in GObject to describe [[metadata]] for object properties (<code>G_TYPE_PARAM</code>).

Types that can be instantiated automatically by the type system are called ''instantiable''. An important characteristic of these types is that the first bytes of any instance always contain a pointer to the ''class structure'' (a form of [[virtual table]]) associated to the type of the instance. For this reason, any instantiable type must be classed. Contrapositively, any non-classed type (such as ''integer'' or ''string'') must be non-instantiable. On the other hand, most classed types are instantiable, but some, such as interface types, are not.

===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.