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 -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (19) 99225-2202 Contact: http://www.gustavobarbieri.com.br/contact ------------------------------------------------------------------------------ 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
