Re: Widget descriptors as unions

[Emmanuele Bassi <ebassi gmail com>]

Hi;

this mailing list is probably not the one you want to use —
development of the GLib/GTK+ libraries is discussed on
gtk-devel-list gnome org 

On 14 May 2015 at 10:27, Jean-Marie Delapierre
<jean-marie delapierre 9online fr> wrote:

> I have coded in C language with GTK+ since a few months.
> In the first times, I have used the usual pointer casting provided with the
> library: GTK_CONTAINER (my_window) for exemple.
>
> In my opinion, there are two disadvantages with this system:
>
> first, the widget pointers are not "object style" written,
> second, if you cast a pointer with a type which is not of one of its parents
> widget, you get no error at compiling time and you get an execution error
> only if you compile with widget type control.
>
> What I suggest is to define the widget descriptors as unions of pointers
> representing the hierarchy of the widgets.

No.

You misunderstand the way unions work in C. You're just adding a bunch
of identically pointer-sized fields inside the same union, which is
entirely pointless since you'll need to know the size of the
allocation of each one of them — thus, you'll need to define a
instance structure for each; it won't also do you any good: you're
exploiting the fact that GObject instance and class structures contain
their parent's instance and class structure, respectively, so
allocating a derived type will automatically allocate enough memory
for you to cast a pointer to its parent type.

Even if we used this trick (which is actually more verbose, more error
prone, and less clear than a cast all at the same time, in itself
quite a feat) you would just consume more space and have no benefit
over the existing 'include the parent structure inside the
instance/class structure of a derived type and cast'. It would also
not solve the issue of interfaces implemented by a type, since you can
add an interface to an existing type without breaking API/ABI, whereas
you cannot change the size of a structure or union compatibly — even
if you are, in effect, just allocating enough room for a single
pointer.

This would also not be API and ABI compatible, so it's an immediate no-go.

> But, there is one disadvantage. This coding style is only available in C and
> C++ languages.

Which is another moot point, since we use the type system for bindings as well.

The GType type system is not without its flaws, but the fact that it's
a run-time type system is not really one of them. It's just the price
you pay for implementing additional types on top of the C type system.
Additionally, any language that allows casting is inherently hard (or,
in some cases, even impossible) to be fully validated at compile time.

Validation of the GType type system should be the realm of static code analysis.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[ ] ebassi [ gmail com]