On Tue, May 3, 2011 at 6:17 AM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Sat, Apr 30, 2011 at 11:59 PM, Gustavo Sverzut Barbieri
> <barbi...@profusion.mobi> wrote:
>> On Sat, Apr 30, 2011 at 1:09 PM, Tom Hacohen <t...@stosb.com> wrote:
>>> On Sat, Apr 30, 2011 at 5:59 PM, Gustavo Sverzut Barbieri
>>> <barbi...@profusion.mobi> wrote:
>>>> On Fri, Apr 29, 2011 at 3:54 PM, Enlightenment SVN
>>>> <no-re...@enlightenment.org> wrote:
>>>> > Log:
>>>> > Eina refcount: Wrap EINA_REFCOUNT_UNREF with do {} while(0).
>>>> > #define EINA_REFCOUNT_UNREF(Variable, Free_Callback) \
>>>> > - if (--((Variable)->__refcount) == 0) \
>>>> > - Free_Callback(Variable);
>>>> > + do \
>>>> > + { \
>>>> > + if (--((Variable)->__refcount) == 0) \
>>>> > + Free_Callback(Variable); \
>>>> > + } \
>>>> > + while (0)
>>>>
>>>> maybe think of a way to set Free_Callback automatically? Spread this
>>>> all around the code will be bad?
>>>
>>> I don't really agree. If the free callback is type specific then you'll get
>>> a compilation warning
>>> when doing something wrong and how different is it from just calling our
>>> custom
>>> unref_my_special_item?
>>>
>>> I.e it's
>>> EINA_REFCOUNT_UNREF(item, free_my_item);
>>> v.s
>>> unref_my_item(item);
>>>
>>> Both are error-prone the same way.
>>>
>>>
>>> Coming to think about it, the current way is not good because it breaks
>>> inheritance.
>>> Here's an example of something that will break:
>>>
>>> struct parent { EINA_REFCOUNT; int foo; };
>>>
>>> struct child { struct parent p; int bar; };
>>>
>>> there's no sane way to do
>>> struct child item;
>>> ...
>>> EINA_REFCOUNT_UNREF(item, free_my_item);
>>> because child->__refcount doesn't exist and passing &child->parent instead
>>> will cause
>>> a compilation warning when calling free_my_item...
>>>
>>> I guess we should drop this refcount thingie, too much hassle and issues.
>>
>> I'm all for dropping it.
>
> I disagree, it's an improvement over having nothing and doing it
> everywhere by our own. With just this macro you have at least a common
> pattern that you can easily understand and track, not something
> depending on the dev who did the job. And more we will use
> Ecore_Thread, more people will need refcount and more we will have
> different implementation of the exact same thing.
Here I disagree based on the following technical reasons:
- you're macro is not thread safe, thus not usable freely with
threads. You rely on specific behavior that does not touch the
reference count at the same time in two threads;
- if you make this thread-safe, then you'd waste resources on
common case that does not require it;
- the code you're "abstracting" is way too simple. Maybe it's worth
to have some coccinele check for the reference count + free if you
want to detect mistakes.
>> Really, I already told that in the past when Andre Dieb was doing
>> EUPnP he asked for similar thing and I said "no, don't go that way,
>> it's not worth"
>
> The cost is 0, the maintenance is 0 also and it improve readability
> and maintenance of the code using it in my opinion. Making it an
> improvement.
I don't agree with that. See above.
>> also, with eina_object, that I dislike the name as in Eina it's better
>> to just have a "memory handle" instead objects. Objects will lead
>> people to expect complex things like 1) inheritance; 2) interfaces; 3)
>> reference counting; 4) type safety (or checking). Putting all of those
>> in C and in making it easy-to-use is impossible... being tried over
>> the past 30 years without success :-P
>
> Right now, Eina_Object is limiting itself to something like
> inheritance (more just like C structure inheritance by packing parent
> on top of the structure), type safety (that was the main purpose of
> it) and memory repacking. I am now planning to add refcount.
you also need some concept of class x instance. Lots of definitions
are easier done per-class and will avoid memory waste and useless
setup cycles. Similar to Evas_Smart x Evas_Object.
> I don't like the idea of adding interfaces to it as it is where the
> cost come most of the time, but that's open for discussion.
Interface is just another pointer in the type (class) definition, It
will contain a list of other types (kludge) or interface definitions
(structure with pointers + identifier).
>> And to this point, if we ever have to implement a new BLA_Object
>> I'm more likely to be against. I'd support using existing object
>> systems that would get us some interpreted language for free, like
>> PyObject (Python) or one of the various JavaScript engines. They
>> already have all these things and expose it to be used in an easier
>> language. And don't be naive to think our would be faster, as soon as
>> we add everything they do, we'd be as slow.
>
> Agreed.
Finally something we agree in this mail! :-D </joke>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
