GObjectification - GSoC progress as of June 16, 2013

[Ethan Blanton]

Jorge Villaseñor spake unto us the following wisdom:
> > - Entities in libpurple have reserved members such as void
> > (*purple_reserved[4])(void), to make it easier to add new API without
> > breaking the ABI for plugins compiled against older versions. Existing
> > GObjectified entities such as PurpleTheme, PurpleThemeManager,
> > PurpleThemeLoader, PurpleSoundTheme and PurpleSoundThemeLoader were
> > missing these padding members, so I added those to them.
> 
> Please someone correct me if I am wrong, but the we want to hide members to
> avoid the need of that purple_reserved members. So we don't have to bump
> the ABI when we add more than 4 more functions.

Well, unfortunately, I think it's somewhat more complicated than that.
Also, as I understand it, moving to GObjects is going to make struct
hiding more difficult for those objects we intend to allow to be
subclassed.

GObject subclassing looks something like this:

struct SubClass {
    struct SuperClass super;

    /* SubClass state */
}

This has several implications, but they all basically boil down to the
fact that the *subclass* has to know the size of the parent class.
Having to know the size means it can't be hidden.  Having to know the
size and maintaining linkage compatability means it can't change size.
So ... we're back where we started.

Any objects that should not be subclassed should have their
implementations hidden to the extent possible, of course.

Ethan