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