Re: What gives us the macro GSEAL()?

[Colomban Wendling <ban-ubuntu club-internet fr>]

Grzegorz Kuczyński a écrit :
> Colomban Wendling pisze:
>> AFAIK, it is used to hide members of GTK+ and GDK structures that
>> will become opaques in future releases (3.0 or so); then it makes
>> easy to see if a source must be updated not to use direct access
>> of members. In practice, compilation of a source code accessing
>> directly struct members with GSEAL_ENABLE defined will fail
>> because member have another name (_g_sealed__<name>).
>>
> So the GSEAL() macro replaces old names.
Yes. It renames them (in a way you're not intended to know) to hide them.
> Because in GTK+ 3 maybe create a new name or type for 'title'
> property and still not erase old members? Old hide in:
> window->_g_sealed__title
>
> I good understand?
No, it is not exactly what I would mean, sorry if I was unclear.
AFAIK (I'm not a GTK+ hacker, I can be wrong) in GTK+ 3.0, structures
may become opaques, opaques meaning that you can't access to members
of those structs because the C compiler doesn't know about them
outside the C file, then not in the header.
In practice, you have in your header something like that in gtkfoo.h:
    typedef struct _GtkFoo GtkFoo;
and in gtkfoo.c:
    struct _GtkFoo { ... };
then in files including gtkfoo.h, only the structure itself is visible
and know, but none of its members.
The main interest I see in disallowing access to members is that it
allows to change the object's internals (by "object" I mean something
like a structure and functions to manipulate it) without breaking
anything outside the object's code itself; e.g. if it make sense to
completely rewrite the GtkWindow structure, the API wouldn't be broken
in any way (and I think it wouldn't broke ABI too, but not sure for
that) since the object's specification doesn't include low-level
implementation details such as structure's members.
This is a concept close to the privates members in some OO languages:
you CAN'T use them outside the object's implementation.
A common opaque object is the C's FILE object that is not defined to
be implemented in a way or another, only functions using this kind of
objects are defined; then any implementation of the FILE object will
work the same way with any source code using it, regardless of what is
needed behind to do the work.

Moreover, it gave more robust objects since the user can't corrupt
them by setting an unexpected value to an object's member (but if
programmers corrupts the libraries they use, they are just stupid,
nothing more).

Well, in simple words, people accessing directly GTK object's members
will have to rewrite their code to use accessors (like
gtk_window_get_title() for the window's title case).

I hope I was clear (and haven't done too much language mistakes, I'm
not English too ;)).

Regards,
Colomban