Replied to you on the vote thread.

--
Tom.

On 09/04/14 15:59, Gustavo Sverzut Barbieri wrote:
> Hi,
>
> Reading the page it seems incorrect regarding some points:
>
>     1. This method is similar to what we have now in legacy, pre-Eo,
> EFL. We create an object and once we "content_set" it, that is, put it
> inside another object, we lose the reference we have. We don't need to
> unref it, as that implies an unref. The downside is, that it's
> implicit, and might confuse people and make them use a ptr after they
> no longer hold the ref.
>
> No, we don't loose the reference. Actually in this Evas there were no
> references at all (just recently _ref/unref were added). What you do
> have is one object explicitly calling delete on the other with
> content_set(), pack and similar. This was done because in widget trees
> you often want to delete the whole tree and not the parent and leave
> the logical children dangling. Some toolkits differentiate these stuff
> with explicit "del" and "deltree", but we don't as we have the most
> common.
>
> GObject uses the concept of floating references, which is exactly to
> address this case. I recommend people read it before voting and that
> we introduce such concept as well:
> https://developer.gnome.org/gobject/unstable/gobject-The-Base-Object-Type.html
>   Basically it says:
>
>      GInitiallyUnowned is derived from GObject. The only difference
>      between the two is that the initial reference of a
>      GInitiallyUnowned is flagged as a "floating" reference. This means
>      that it is not specifically claimed to be "owned" by any code
>      portion. The main motivation for providing floating references is
>      C convenience. In particular, it allows code to be written as:
>
>          container = create_container ();
>          container_add_child (container, create_child());
>
>      If container_add_child() calls g_object_ref_sink() on the
>      passed-in child, no reference of the newly created child is
>      leaked. Without floating references, container_add_child() can
>      only g_object_ref() the new child, so to implement this code
>      without reference leaks, it would have to be written as:
>
>          Child *child;
>          container = create_container ();
>          child = create_child ();
>          container_add_child (container, child);
>          g_object_unref (child);
>
>      The floating reference can be converted into an ordinary reference
>      by calling g_object_ref_sink(). For already sunken objects
>      (objects that don't have a floating reference anymore),
>      g_object_ref_sink() is equivalent to g_object_ref() and returns a
>      new reference.
>
>      Since floating references are useful almost exclusively for C
>      convenience, language bindings that provide automated reference
>      and memory ownership maintenance (such as smart pointers or
>      garbage collection) should not expose floating references in their
>      API.
>
>
>
> That said, this usage of floating shouldn't be a policy for whole EO,
> rather chosen for each usage pattern.
>
> On Wed, Apr 9, 2014 at 6:35 AM, Tom Hacohen <tom.haco...@samsung.com> wrote:
>> Hey guys,
>>
>> I've started a poll regarding the behaviour of Eo and refcounts. We
>> would like to hear everyone out. This is not a super low level Eo issue,
>> but actually an API issue that will affect app developers as well.
>>
>> Everyone on this list is welcomed and encouraged to reply to the poll.
>>
>> https://phab.enlightenment.org/V7
>>
>> Thanks,
>> Tom.
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
>


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to