| | | | |abstract Efl.Object | | | | |├ (P) parent | | | | |├ (P) name | | | | |├ (P) comment | | | | |├ (P) event_global_freeze_count | | | | |├ (P) event_freeze_count | | | | |├ (P) finalized | | | | |├ (P) invalidated | | | | |├ (P) invalidating | | | | |├ (P) allow_parent_unref | | | | |├ (M) debug_name_override | | | | |├ (M) provider_find | | | | |├ (M) constructor | | | | |├ (M) destructor | | | | |├ (M) finalize | | | | |├ (M) invalidate | | | | |├ (M) noref | | | | |├ (M) name_find | | | | |├ (M) event_thaw | | | | |├ (M) event_freeze | | | | |├ (M) event_global_thaw | | | | |├ (M) event_global_freeze | | | | |├ (M) event_callback_stop | | | | |├ (M) event_callback_forwarder_priority_add | | | | |├ (M) event_callback_forwarder_del | | | | |├ (M) children_iterator_new | | | | |├ (M) composite_attach | | | | |├ (M) composite_detach | | | | |├ (M) composite_part_is | | | | |├ (E) del | | | | |├ (E) invalidate | | | | |├ (E) noref | | | | |├ (E) destruct
If you mean the lifecycle calls, I agree completely. I'd love to understand what do (P) finalized, (P) invalidated, (P) invalidating, (M) finalize, (M) invalidate, (M) noref, (E) del, (E) invalidate, (E) noref and (E) destruct mean.
This output needs to be updated but the lua script I was using doesn't work anymore.
In short, the lifecycle works something like this:
- constructor - callback for instantiating the class
- finalize - callback for after the constructors are called but before the created object is returned
- invalidate - occurs when an object's parent has been unset (parent_set(NULL))
- noref - occurs when the object's refcount reaches 0
- del - occurs when the object starts to be deleted
- destruct - occurs when the object is destroyed
There are some functions for determining exactly where in the deletion chain an object is:
- invalidated - the object's parent has been unset
- invalidating - the object's parent is being unset (i.e., during the parent_set(NULL) call)
@lauromoura Afaics this only affects bindings, but not the efl.object definition perse. @segfaultxavi improved the documentation big time. To me the API looks good, except one tiny thing, i don't know if we want to have allow_parent_unref out of beta or not, because to me this seems like a hack that should not be needed in future, opinions @zmike @cedric.