[webkit-efl] Common ref and unref functions for EFL WK2 objects

[Pozdnyakov, Mikhail]

Hi,

First version of the patch you can see at bug https://bugs.webkit.org/show_bug.cgi?id=100751.

I do not believe performance is issue here: we have only one extra pointer comparison per external API call (which BTW are not called very frequently, like paint event handler for instance).

As for benefits, besides the avoiding of copy/pasting of ref/unref code in a lot of places I could also mention ability to write common allocation/deallocation code, take example of  freeing Eina_list

EINA_LIST_FREE(*list, data) {
     ewk_ref_counted_unref((Ewk_Ref_Counted*)data);
}

and this will fit for every ref-counted object.

> However, it becomes less obvious which objects ewk_ref() / ewk_unref() can be used on
Currently the user opens the header to see smth like ewk_intent_ref() function, after the change 
the user see smth like  typedef struct Ewk_Ref_Counted Ewk_Back_Forward_List_Item;
Not much change to my mind.

BR,
Mikhail

________________________________________
From: Dumez, Christophe [christophe.dumez at intel.com]
Sent: Wednesday, October 31, 2012 2:56 PM
To: Pozdnyakov, Mikhail
Cc: webkit-efl at lists.webkit.org
Subject: Re: [webkit-efl] Common ref and unref functions for EFL WK2 objects

Hi,

In my opinion, the impact on the public API is small:
  - Client calls ewk_ref(intent) / ewk_unref(intent) instead of calling ewk_intent_ref(intent) / ewk_intent_unref(intent).

The code is slightly smaller, yes. However, it becomes less obvious which objects ewk_ref() / ewk_unref() can be used on.

I'm also worried about the internal changes needed to make this small API change. I'm waiting to see the patch but the code
involved in doing this is probably not that small and may have performance impact (especially if you need to recognize the object type at run time).

Kr,

On Tue, Oct 30, 2012 at 12:04 PM, Pozdnyakov, Mikhail <mikhail.pozdnyakov at intel.com<mailto:mikhail.pozdnyakov at intel.com>> wrote:
Hi,

I've already mentioned the proposal at
http://lists.webkit.org/pipermail/webkit-efl/2012-October/000393.html

but think (and since nobody replied so far) it deserves new topic and new thread, so duplicating proposal again here.

As all the ref-counting EWK classes are inherited from WTF::RefCounted
it is possible now to have generic REF/UNREF functions in the public API instead of
having separate pair of such functions for every object.

To say in more details we could introduce
struct Ewk_Ref_Counted Ewk_Ref_Counted;
and following generic functions:
EAPI Ewk_Ref_Counted*  ewk_ref(Ewk_Ref_Counted*);
EAPI  ewk_unref(Ewk_Ref_Counted*);

then Ewk_Back_Forward_List_Item  might be declared for instance as

typedef Ewk_Ref_Counted Ewk_Back_Forward_List_Item;

so that it's clear that Ewk_Back_Forward_List_Item is ref-countable
(or we could just mention in docs that given object is ref counted).

Would like to hear your opinion about this proposal.

BTW, WK2 C API has geneiric ref/unfer functions and GTK also does.

BR,
Mikhail
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

_______________________________________________
webkit-efl mailing list
webkit-efl at lists.webkit.org<mailto:webkit-efl at lists.webkit.org>
http://lists.webkit.org/mailman/listinfo/webkit-efl



--
Christophe Dumez
Linux Software Engineer, PhD
Intel Finland Oy - Open Source Technology Center

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.