Some aspects of the GObjectification approach

[Elliott Sales de Andrade]

On 1 June 2013 17:23,  <gillou.ray at free.fr> wrote:
> 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.
>

Is it not possible to use GObject introspection to hook this up? I'm
not sure which one you used, but it looks like both dbus-glib and its
replacement GDbus can use introspection data of some sort to create
their DBus equivalents. Maybe it's only DBus introspection data
though.

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

-- 
Elliott aka QuLogic
Pidgin developer