summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKai Huuhko <kai.huuhko@gmail.com>2017-07-09 16:50:24 +0300
committerKai Huuhko <kai.huuhko@gmail.com>2017-07-09 16:50:24 +0300
commit5864a9dd2d5d43461f9098708fbf14cf53a0f116 (patch)
treeee2f208bfe248f68d35a7def25e44f9648461dd3
parenta475ecba44220bf4c262c93033ec86d0041ab555 (diff)
Documentation: Add better documentation about object lifetime
-rw-r--r--doc/efl.rst20
-rw-r--r--efl/eo/efl.eo.pyx14
2 files changed, 30 insertions, 4 deletions
diff --git a/doc/efl.rst b/doc/efl.rst
index 6725dae..b21e87d 100644
--- a/doc/efl.rst
+++ b/doc/efl.rst
@@ -6,6 +6,26 @@
6.. versionadded:: 1.8 6.. versionadded:: 1.8
7 7
8 8
9Object lifetime
10---------------
11
12Eo objects (and any which have the delete() method) get their reference count
13internally increased by one at object creation. This means that these objects
14will not get freed when you release all references to them in your application.
15You must call the objects' delete() method to decrease the internal reference
16count. This will usually also trigger some kind of action to destroy
17the object gracefully, i.e. hiding the graphical object etc, and will set the
18C object pointer to NULL, which will prevent you from calling methods on the
19object.
20
21If you can't keep track of when your application calls the delete method, you
22can check that your object is still valid with either the is_deleted() method,
23or with a non-zero check::
24
25 if eo_obj:
26 print(repr(eo_obj))
27
28
9Logging 29Logging
10------- 30-------
11 31
diff --git a/efl/eo/efl.eo.pyx b/efl/eo/efl.eo.pyx
index cc0c60a..6985308 100644
--- a/efl/eo/efl.eo.pyx
+++ b/efl/eo/efl.eo.pyx
@@ -283,11 +283,17 @@ cdef class Eo(object):
283 return EoIterator.create(efl_children_iterator_new(self.obj)) 283 return EoIterator.create(efl_children_iterator_new(self.obj))
284 284
285 def delete(self): 285 def delete(self):
286 """Delete the object and free internal resources. 286 """Decrease internal reference count and delete the object gracefully
287 287
288 .. note:: This will not delete the python object, but only the internal 288 .. note:: Reference count will be decreased at the del callback, not
289 C one. The python object will be automatically deleted by the 289 instantly when calling this. Same for setting the internal
290 garbage collector when there are no more reference to it. 290 object pointer to NULL and freeing any internal resources.
291
292 .. note:: This will not automatically free the Python object, only
293 the wrapped C object. This will prevent you from calling methods
294 other than :meth:`is_deleted` and accessing properties on the
295 object. The Python object will be automatically freed by Python
296 when there are no more references to it.
291 297
292 """ 298 """
293 efl_del(self.obj) 299 efl_del(self.obj)