GObject

De Wikipedia, la enciclopedia libre

Esta página o sección está siendo traducida del idioma inglés a partir del artículo GObject, razón por la cual puede haber lagunas de contenidos, errores sintácticos o escritos sin traducir.
Puedes colaborar con Wikipedia continuando con la traducción desde el artículo original

Una pieza típica del código de inicialización de la clase GObject. El ejemplo muestra una propiedad file-size siendo añadida a alguna clase.

GLib Object System, o GObject, es una biblioteca de software libre bajo la licencia LGPL que provee un sistema de objetos portable y una interoperabilidad multilenguaje transparente. GObject está diseñado para su utilización directa en programas C y a través de bindings, a otros lenguajes.

Contenido

1 Historia
2 Relación con GLib
3 El sistema de tipos
- 3.1 Tipos fundamentales
- 3.2 Tipos derivados
4 Sistema de mensajería
5 Class implementation
6 Uso
7 Comparisons to other object systems
8 Véase también
9 Enlaces externos

[editar] Historia

Dependiendo sólo de GLib y libc, GObject es la piedra angular de GNOME y es utilizada en todo GTK+, Pango, Accessibility Toolkit, y la mayoría de aplicaciones y bibliotecas de alto nivel de GNOME. Antes de GTK+ 2.0, el código GObject era parte del código base de GTK+. (El nombre de "GObject" todavía no estaba en uso; el nombre común de la clase base fue llamado GtkObject.)

La liberación de GTK+ 2.0 tenía extraído el sistema de objetos en una biblioteca separada debido a su utilidad general. En el proceso, la mayoría de GUI no específica de partes de la clase GtkObject se trasladó hasta GObject, la nueva clase base común. Habiendo existido como una biblioteca separada desde el 11 de marzo de 2002 (la fecha de lanzamiento de GTK+ 2.0), la biblioteca GObject es ahora utilizada por muchos programas sin GUI como la línea de comandos y las aplicaciones de servidor.

[editar] Relación con GLib

Aunque GObject tiene su propio conjunto separado de documentación [1] y esta normalmente compilado en su propio archivo de biblioteca compartida, el código fuente de GObject reside en el árbol de código fuente GLib y se distribuye junto con GLib. Por esta razón, GObject utiliza los números de versión de GLib y suele ser empaquetado junto con GLib (por ejemplo, Debian pone GObject en su familia de paquetes libglib2.0).

[editar] El sistema de tipos

En el nivel más básico del framework de GObject radica un tipo de dato genérico y dinámico llamado GType. El sistema GType mantiene una descripción en tiempo de ejecución de todos los objetos que permiten encolar código para facilitar múltiples bindings de lenguajes. El sistema de tipos puede manejar cualquier estructura de clase de herencia múltiple, además de tipos sin clase como punteros opacos, cadenas, y varios tamaños de números de enteros y punto flotante.

El sistema de tipo sabe cómo copiar, asignar y destruir valores pertenecientes a cualquiera de los tipos registrados. Esto es trivial para los tipos como enteros, pero muchos objetos complejos son contados por referencia, mientras que algunos son complejos pero no contados por referencia. Cuando el tipo de sistema "copia" un objeto de referencia contada, normalmente sólo aumentará su referencia contada, mientras que cuando se copia uno complejo, no un objeto de referencia contada (como una cadena), se suele crear una copia actual por asignación de memoria.

Esta funcionalidad básica se utiliza para implementar GValue, un tipo de contenedor genérico que puede contener valores de cualquier tipo conocido por el sistema de tipo. Estos contenedores son particularmente útiles cuando interactúan dinámicamente con entornos de lenguajes tipados en los que todos los valores nativos residen en contenedores de tipos etiquetados.

[editar] Tipos fundamentales

Tipos que no tienen ninguna clase asociada se denominan no claseados. Estos tipos, junto con todos los tipos que corresponden a alguna forma de la clase raíz, son conocidos como tipos fundamentales: los tipos a partir de la cual todos los otros tipos se derivan. Estos conforman un conjunto relativamente cerrado, pero aunque el usuario medio no se espera crear sus propios tipos fundamentales, la posibilidad existe y ha sido explotada para crear jerarquías de clase personalizadas - por ejemplo, las jerarquías de clase no basadas en la clase GObject.

A partir de GLib 2.9.2 [2], los tipos no claseados fundamentales integrados son

un tipo vacío, correpondiente al void de C (G_TYPE_NONE);
tipos correspondientes a los tipos con signo y sin signo de C char, int, long y enteros de 64-bit (G_TYPE_CHAR, G_TYPE_UCHAR, G_TYPE_INT, G_TYPE_UINT, G_TYPE_LONG, G_TYPE_ULONG, G_TYPE_INT64 y G_TYPE_UINT64);
un tipo booleano (G_TYPE_BOOLEAN);
un tipo enumerado y un tipo "flags”, ambos corresponientes al tipo enum de C, pero difiriendo en que este último es solo usado para campos de bit (G_TYPE_ENUM y G_TYPE_FLAGS);
tipos para simple y doble precisión IEEE punto flotante, correspondiente al float y double de C (G_TYPE_FLOAT y G_TYPE_DOUBLE);
un tipo cadena, correspondiente al char * de C (G_TYPE_STRING);
un tipo de puntero opaco, correspondiente al void * de C (G_TYPE_POINTER).

Los tipos claseados fundamentales integrados son:

un tipo de clase base para instancias de GObject, la raíz de la clase estándar de árbol de herencia (G_TYPE_OBJECT)
un tipo de interfaz base, análogo a tipo de clase base pero representando la raíz de la interfaz estándar del árbol de herencia (G_TYPE_INTERFACE)
un tipo para la estructura boxed, que es usada para envolver valores simples de objetos o objetos ajenos a las "boxes" de referencia contada (G_TYPE_BOXED)
un tipo para "especificaciones de parámetros de objetos", que son usados en GObject para describir metadatos para propiedades de objetos (G_TYPE_PARAM).

Los tipos que puede ser instanciados automáticamente por el sistema de tipos son llamados instanciables. Una característica importante de esos tipos es que el primer byte de cualquier instancia siempre contiene un puntero a la estructura de clase (una forma de tabla virtual) asociada al tipo de la instancia. Por esta razón, cualquier tipo instanciable debe ser claseado. Contrapositivamente, cualquier tipo no claseado (como integer o string') debe ser no instanciable. Por otro lado, la mayoría de los tipos claseados son instanciables, pero algunos, como los tipos de interfaces, no lo son.

[editar] Tipos derivados

Los tipos que se derivan de la integración de los tipos fundamentales GObject recaen aproximadamente en cuatro categorías:

Tipos enumerados y tipos “flags”: En general, cada tipo enumerado y cada tipo con campo de bit basado en entero (por ejemplo, cada tipo enum) que uno desea utilizar de alguna manera está relacionado con el sistema de objeto - por ejemplo, como el tipo de una propiedad de objeto - deben ser registrados con el sistema de tipo. Normalmente, el código de inicialización que se encarga de registrar estos tipos es generado por una herramienta automatizada llamado glib-mkenums [3] y se almacenan en un archivo separado.

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 background-color property, whose values should be instances of a structure that looks like struct color { int r, g, b; }. To avoid having to subclass GObject, 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. While such objects can be used in GObject by simply treating them as opaque pointers (G_TYPE_POINTER), 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 — in the normal object-oriented sense of the word — derived directly or indirectly from the root class, GObject. There are also Java-style interfaces, although as of 2006 these are still relatively rarely used, likely because they have only been around since GLib 2.4 (which was released on March 16, 2004). The GNU Image Manipulation Program uses GObject interfaces.

[editar] Sistema de mensajería

The GObject messaging system consists of two complementary parts: closures and signals.

Closures: A GObject closure is a generalized version of a callback. Support exists for closures written in C and C++, as well as arbitrary languages (when bindings are provided). This allows code written in (for example) Python and Java to be invoked via a GObject closure.

Signals: Signals are the primary mechanism by which closures are invoked. Objects register signal listeners with the type system, specifying a mapping between a given signal and a given closure. Upon emission of a registered signal, that signal's closure is invoked. In GTK+, all native GUI events (such as mouse motion and keyboard actions) can generate GObject signals for listeners to potentially act upon.

[editar] Class implementation

Each GObject class is implemented by at least two structures: the class structure and the instance structure.

The class structure: The class structure corresponds to the vtable of a C++ class. It must begin with the class structure of the superclass. Following that, it will hold a set of function pointers — one for each virtual method of the class. Class-specific variables can be used to emulate class members.
The instance structure: The instance structure, which will exist in one copy per object instance, must begin with the instance structure of the superclass (this ensures that all instances begin with a pointer to the class structure, since all fundamental instantiable types share this property). After the data belonging to the superclass, the structure can hold any instance-specific variables, corresponding to C++ member variables.

Since a C structure cannot have access modifiers like “public”, “protected”, or “private”, a common technique is to include a pointer to the private data — conventionally called _priv — in the instance structure. The private structure can be declared in the public header file, but defined only in the implementation file, with the effect that the private data is opaque to users, but transparent to the implementor. If the private structure is registered with GType, it will be automatically allocated by the object system. Indeed, it is not even necessary to include the _priv pointer, if one is willing to utter the incantation G_TYPE_INSTANCE_GET_PRIVATE every time the private data is needed.

The main drawback of the GObject framework is its verbosity. Large amounts of boilerplate code, such as manual definitions of type casting macros and obscure type registration incantations, are necessary to create a new class. The GObject Builder, or GOB2, is a tool that attempts to remedy this problem by offering a template syntax reminiscent of Java. Code written using GOB2 is pre-processed into vanilla C code prior to compilation. Another compiler-to-C for the GObject type system is Vala, which uses a C#-style syntax.

[editar] Uso

The combination of C and GObject is used in many successful free software projects, such as the GNOME desktop, the GTK toolkit and the GIMP image manipulation program.

Though many GObject applications are written entirely in C, the GObject system maps nicely into the native object systems of many other languages, like C++, Java, Ruby, Python, and .NET/Mono. As a result, it is usually relatively painless to create language bindings for well-written libraries that use the GObject framework.

Writing GObject code in C in the first place, however, is relatively painful. The learning curve is quite steep, and programmers with experience in high-level object-oriented languages are likely to find it very tedious to work with GObject in C. For example, creating a non-trivial subclass (even just a subclass of GObject) can require writing and/or copying hundreds of lines of code. Nevertheless, adopting GObject can lead to a significant improvement of C code that is, or wants to be, object-oriented.

Although they are not really first-class objects (there are no actual metatypes in GType), metaobjects like classes and interfaces are created by GObject applications at runtime, and provide good support for introspection. The introspective capabilities are used by language bindings and user interface design applications like Glade to allow doing things like load a shared library that provides a GObject class - usually some kind of widget, in the case of Glade - and then obtain a list of all properties of the class, complete with type information and documentation strings.

[editar] Comparisons to other object systems

Since GObject provides a complete object system for C, it can be seen as an alternative to C-derived languages such as C++ and Objective-C. (Though C++, in particular, also has many other features apart from its object system.) An easily observed difference between C++ and GObject is that GObject (like Java) does not support multiple inheritance.

Another important difference is that while C++ and Objective-C are separate languages, GObject is strictly a library and as such does not introduce any new syntax or compiler intelligence. For example, when writing GObject-based C code, it is frequently necessary to perform explicit upcasting. Hence, “C with GObject” is a strict superset of plain C — unlike C++.

Since there is no standard ABI that works across all C++ compilers (except on Windows, where COM serves that function), a library compiled with one C++ compiler is not always able to call a library compiled with a different one. If such compatibility is required, the C++ methods must be exported as plain C functions, partly defeating the purpose of the C++ object system. The problem occurs in part because different C++ compilers use different kinds of name mangling to ensure the uniqueness of all exported symbols. (This is necessary because, for example, two different classes may have identically named member functions, one function name may be overloaded multiple times, or identically named functions may appear in different namespaces.) In contrast, since C does not support any form of overloading or namespacing, authors of C libraries will typically use explicit prefixes to ensure the global uniqueness of their exported names. Hence, despite being object-oriented, a GObject-based library written in C will always use the same external symbol names regardless of which compiler is used.

Perhaps the most profound difference is GObject’s emphasis on signals. This emphasis derives from the fact that GObject was specifically designed to meet the needs of a GUI toolkit. To be sure, there are signal libraries for most object-oriented languages out there, but in the case of GObject it is built right into the object system. Because of this, a typical GObject application will tend to use signals to a much larger extent than a non-GObject application would, making GObject components much more encapsulated and reusable than the ones using plain C++ or Java.