Some aspects of the GObjectification approach

[Ankit Vani]

Hi Mark and Tomek

On 7 October 2013 13:08, Mark Doliner <mark at kingant.net> wrote:
> On Sat, Jun 1, 2013 at 12:13 PM, Ankit Vani <a at nevitus.org> wrote:
>> 2. Data fields
>> We do not need to have protocol data and UI data fields on objects.
>> For that, we can use subclasses. For example, we can have GObject <-
>> PurpleBlistNode <- PurpleBuddy <- XMPPBuddy. If we cannot subclass, we
>> can use or g_object_set_data().
>
> Is this plan still accurate? I notice that PurpleAccount still has
> "gpointer ui_data," purple_account_set_ui_data(), and
> purple_account_get_ui_data(). It looks like these maybe aren't used
> for PurpleAccount, but it looks like there are other objects with a
> ui_data field that IS still used.

No, the original plan is not implemented as you noticed. There were a few
problems with that approach.

First of all, things can either be subclassed by the protocol (protocol_data),
or by the UI (ui_data) -- but not by both. So to avoid some components being
subclassed by protocols and some by the UI (and switching between them in the
future), and thus causing confusion, I decided that only protocols should
subclass core libpurple types. This is done using PurpleProtocolFactoryIface in
the soc.2013.gobjectification.plugins branch, which provides callbacks via which
protocols can return instances of the subtypes they define.

The sequence of subclassing cannot be dynamic because a subclass struct must
have a parent class member for the inheritance, and thus the parent must be
fixed.

On 7 October 2013 13:13, Tomasz Wasilczyk <twasilczyk at pidgin.im> wrote:
> In my opinion, all purple_account_set_ui_data uses should just be
> converted to g_object_set_data.

Thats a much better design, and was the original plan as well. However, I
noticed g_object_[sg]et_data() used data lists (GData), which looked up keys
linearly. Thus, if we had say five data sets set for a GObject, the time to
access the UI data increases five times. And if we had a buddy list with like
1000 nodes, each with a UI data, the time needed to display the buddy list
increases 5000 times. New data sets are prepended to the list and UI data is
generally set first, so accessing it is most definitely going to take the worst
case time.

I decided to keep the ui_data fields to avoid any kind of performance loss for
the UI.

Please let me know if there is a fault in my reasoning, or if you think the
possible performance loss is alright and not going to be noticable.

Ankit