GObjectification - GSoC progress as of June 16, 2013

Nader Morshed morshed.nader at gmail.com
Wed Jun 19 03:37:55 EDT 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 18 Jun 2013 23:22:33 -0400
Ethan Blanton <elb at pidgin.im> wrote:

> 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.

FWIW, there's G_SEAL to force callers to use the methods to access
object properties: https://live.gnome.org/GnomeGoals/UseGseal

Then you can either dummy pointers as padding for forward
compatibility, but another possible option is to add a field that
versions the structures and add conditional code to the getters /
setters. The trade-off better future-proofing for bulkier code. The
FreeBSD project discusses it in their standards for maintaining binary
compatibility: https://wiki.freebsd.org/BinaryCompatibility

I suspect the pidgin devs will probably speak against the latter point,
but just thought I'd throw it in as my 2 cents...

- --
Nader Morshed <morshed.nader at gmail.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQIcBAEBAgAGBQJRwV/UAAoJEKfs8q3oqdgM6U0P/0pXbHXk9VfzXCis5waS0Mv4
kpC/4eYvdfdsLW8gVADDWTnb7l4K25JWWUuWkkgPi82gBn/IDdp3veyKqiemcBDK
0NjCP9aOmg7o7n0jIhl1xjqqMFBjimLbCQ0Ei9pYSf9cZF4B5eRB8uGlYI+wh3AX
4PzHZzAeH6l8pphpQDCaHxrUkYuMfoYGLIIJV/czFglVya2O5Dk7CMgbP/nM7myu
/KDshYw861rz2OYfr8XES6Q7GR788ltKPRLeO/1QGYR4eNuiPr0mpsKiFP5M3skq
EDsbgHqqcAnRE24U3J0gy5s8dZjvizc1i091yZI4LREZ9ZYemo21jWhSHdQKhuHf
kxl+QelERJBDVMd4VFFQVL2exPuDxwkXiAVMyYgr8vEC7icgRQH/Z/LR8OqrmvYi
gtEkj6bDO+7wVDGAvYxixd6T8X9zmFWjf2teG8o6JsgpNQTxsG7UAS9pttfZgvHK
QfK34kHoQIiuVo1wWHPOuVoBastPpi6zcTz3Of/fLQYef1Nv3gXxtpMJbulo2XM5
t/U9Q/GJ3/XMUx5Aqu5kvFVKDVcD8n3JgmH6hbS8m9m5tL/3vF1JzclUJVRL4b3t
5HWUxaMoiH8tIw6foM28HkBVgbvMvOWsrJCQh7FK/xfPz0AT9WXt6fg010XRSoir
EeGj75UqqiDu+dQmei06
=xfcs
-----END PGP SIGNATURE-----



More information about the Devel mailing list