On Sat, Apr 30, 2011 at 1:09 PM, Tom Hacohen <[email protected]> wrote:
> On Sat, Apr 30, 2011 at 5:59 PM, Gustavo Sverzut Barbieri
> <[email protected]> wrote:
>>
>> On Fri, Apr 29, 2011 at 3:54 PM, Enlightenment SVN
>> <[email protected]> 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.
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"
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
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.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
