Some aspects of the GObjectification approach

[gillou.ray at free.fr]

On Sun, 2 Jun 2013 00:43:56 +0530
Ankit Vani <a at nevitus.org> wrote:

> In my proposal, I suggested using PurpleObject as a base to all purple
> classes. But PurpleObject doesn't really buy us anything and wastes
> memory instead. The objects can inherit GObject directly and any
> mechanism that would require PurpleObject would just be more flexible
> by using GObjects instead.

Hmm in my detachable sessions project I’ve been using PurpleObjects as a
mean to make our objects DBus-capable. That is to say, to add DBus init
methods and to allow binding DBus methods, for every object [1]. Now
you’re mentioning this, I think too this is a waste of memory since
probably not every object is gonna need to show up on DBus. In theory it
would make more sense to have this DBus stuff defined into an
interface, only implemented by the relevant DBus-interested objects. In
practice I never played with gobject’s interfaces so I’m not 100% sure
using interfaces will be fine.

I’d say go on and remove PurpleObjects. After all switching from
PurpleObject inherited to GObject inherited objects is a matter of
search-and-replace, so it’s not a big deal to revert if you change your
mind afterwards.

[1] http://hg.pidgin.im/cpw/gillux/detachablepurple/file/e5cd1fe40bea/libpurple/pobject.h#l47

		— gillux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://pidgin.im/pipermail/devel/attachments/20130601/a8f1e586/attachment-0002.sig>