Eo: Better define the relationship of eo_add/del/ref/unref.
authorTom Hacohen <tom@stosb.com>
Tue, 30 Sep 2014 13:27:43 +0000 (14:27 +0100)
committerTom Hacohen <tom@stosb.com>
Tue, 30 Sep 2014 13:53:09 +0000 (14:53 +0100)
Now it's more clear and consistent. This commit complements the previous
eo_add commit (a7560dbc61953c3652780f232e38adbd2d711972).

Now eo_add should be matched with eo_del
eo_ref with eo_unref
eo_add_ref with eo_unref + eo_del

Essentially, the change is that if you have the ref to an object, you
need to unref it. Thus making ref/unref unneeded for most people who use
things (carefully) in c. If however, you would like to delete an object
previously created by you, you should eo_del (counter-part to eo_add).

It's still recommended you ref/unref when dealing with objects in
scopes, as you can't know when an object might just get deleted as a
by-product of another call.

This fixes an issue found by JackDanielZ.

src/lib/eo/eo.c
src/lib/eo/eo_private.h

index fa64ce135f59ce2483f32111c229ddafaa0e6a78..e78b6f0f246fbc66299ba37431658bd198422e83 100644 (file)
@@ -1546,7 +1546,14 @@ eo_unref(const Eo *obj_id)
 EAPI void
 eo_del(const Eo *obj)
 {
-   eo_unref(obj);
+   if (eo_do(obj, eo_parent_get()))
+     {
+        eo_do(obj, eo_parent_set(NULL));
+     }
+   else
+     {
+        eo_unref(obj);
+     }
 }
 
 EAPI int
index 1c21d2255e16e5859e67defccb30c1baefb5f312..be0a03a09d3bf9f4fc89233a833b1f36ac9430ba 100644 (file)
@@ -284,16 +284,6 @@ _eo_unref(_Eo_Object *obj)
              return;
           }
 
-        /* Unparent if parented. */
-          {
-             Eo *eo_id = _eo_id_get(obj);
-             obj->refcount = 2; /* Needs to be high enough that parent set to null won't delete the object. */
-
-             eo_do(eo_id, eo_parent_set(NULL));
-
-             obj->refcount = 0;
-          }
-
         _eo_del_internal(__FILE__, __LINE__, obj);
 
 #ifdef EO_DEBUG