Package: glib
GBoxed g-variant-type
Superclassescommon-lisp:standard-object, common-lisp:t Documented Subclasses
None
Direct Slots
None
Details
The GVariant type system is based, in large part, on the D-Bus type system,
with two major changes and some minor lifting of restrictions.
The D-Bus specification, therefore, provides a significant amount of information that is useful when working with g-variant values. The first major change with respect to the D-Bus type system is the introduction of maybe (or "nullable") types. Any type in the GVariant type system can be converted to a maybe type, in which case, "nothing" (or "null") becomes a valid value. Maybe types have been added by introducing the character "m" to type strings. The second major change is that the GVariant type system supports the concept of "indefinite types" - types that are less specific than the normal types found in D-Bus. For example, it is possible to speak of "an array of any type" in the GVariant type system, where the D-Bus type system would require you to speak of "an array of integers" or "an array of strings". Indefinite types have been added by introducing the characters "*", "?" and "r" to type strings. Finally, all arbitrary restrictions relating to the complexity of types are lifted along with the restriction that dictionary entries may only appear nested inside of arrays. Just as in D-Bus, GVariant types are described with type strings. Subject to the differences mentioned above, these strings are of the same form as those found in D-Bus. Note, however: D-Bus always works in terms of messages and therefore individual type strings appear nowhere in its interface. Instead, "signatures" are a concatenation of the strings of the type of each argument in a message. The GVariant type system deals with single values directly so GVariant type strings always describe the type of exactly one value. This means that a D-Bus signature string is generally not a valid GVariant type string - except in the case that it is the signature of a message containing exactly one argument. An indefinite type is similar in spirit to what may be called an abstract type in other type systems. No value can exist that has an indefinite type as its type, but values can exist that have types that are subtypes of indefinite types. That is to say, the function g-variant-type will never return an indefinite type, but calling the function g-variant-is-of-type with an indefinite type may return true. For example, you cannot have a value that represents "an array of no particular type", but you can have an "array of integers" which certainly matches the type of "an array of no particular type", since "array of integers" is a subtype of "array of no particular type". This is similar to how instances of abstract classes may not directly exist in other type systems, but instances of their non-abstract subtypes may. For example, in GTK, no object that has the type of gtk-bin can exist, since gtk-bin is an abstract class, but a gtk-window can certainly be instantiated, and you would say that the gtk-window is a gtk-bin, since gtk-window is a subclass of gtk-bin. A detailed description of GVariant type strings is given here: GVariant Type StringsA GVariant type string can be any of the following:
The above definition is recursive to arbitrary depth. "aaaaai" and "(ui(nq((y)))s)" are both valid type strings, as is "a(aa(ui)(qna{ya(yd)}))". The meaning of each of the characters is as follows:
"a{?*}" is an indefinite type that is a supertype of all arrays containing dictionary entries where the key is any basic type and the value is any type at all. This is, by definition, a dictionary. Note that, due to the restriction that the key of a dictionary entry must be a basic type, "{**}" is not a valid type string. Two types may not be compared by value. Use the functions g-variant-type-equal or g-variant-type-is-subtype-of. May be copied using the function g-variant-type-copy and freed using the function g-variant-type-free. | See also |
2021-7-31