This should not happen. Objects with parents must have their parents
unset before they reach refcount == 0. That's because the parent is the
one holding the refcount. This means that if we get to the destructor
(object is deleted) while a parent is still set, we have an error
scenario.
After this change, parent_set assigns a ref, so for example:
obj = eo_add(CLASS, parent); /* Ref is 1 */
eo_do(obj, eo_parent_set(parent2)); /* Ref is 1 */
eo_ref(obj); /* Ref is 2 */
eo_do(obj, eo_parent_set(NULL)); /* Ref is 1, giving the ref to NULL */
eo_do(obj, eo_parent_set(parent)); /* Ref is 1 */
This is following a discussion on the ML about commit
8689d54471.
@feature
optimization
xrefs keep lists of objects references. children are already in a list.
why keep both? lots of extra memory used for no value when debug is on
(pretty much most of the time).
this follows on from cbc1a217bf as this
code was correct, but was then causing bugs due to children staying in
their parent lists. this should never have happened and this is really
bad. this fixes this and ensures children on destruction are gone from
their parent lists.
@fix
it is possible that a destructor/parent_set override or function could
go modifying the children list of objects in a parent, this the
EINA_LIST_FREE may actually miss objects in the process since within
the "free" func the list may have been altered etc.
@fix
This was not really useful and against the Eolian guidelines.
While I promised I won't break things until the 27th, I was ill
(still am), so I'm giving myself a 1 day pass. :P
This is another cleanup in perparation for the Eo stable release.
This is no longer needed thanks to the proper error reporting with
eo_constructor()'s new return value.
The finalizer change cleans it up a bit so it catches more cases/issues.
This also means that the finalizer cleans up the object in all cases,
and not only some.
@feature.
From now on, constructors should return a value, usually the object
being worked on, or NULL (if the constructor failed). This can also
be used for implementing singletons, by just always returning the same
object from the constructor.
This is one of the final steps towards stabilizing Eo.
@feature
This affects eo_do() and eo_add() that used to use the ({}) GCCism.
Following a discussion with Peter de Ridder after my talk at FOSDEM,
we've decided to reopen the GCCism (works with other gcc compatible
compilers like clang and intelc) discussion, and after a bit of back and
forth it was decided to make things more portable, at the cost of ease
of use.
For example:
if (eo_do(obj, visible_get()))
is no longer allowed, the portable alternative
Eina_Bool tmp;
if (eo_do_ret(obj, tmp, visible_get()))
is to be used instead.
However:
eo_do(obj, a = a_get(), b = b_get(), bool_set(!bool_get))
are still allowed and OK.
eo_do(obj, if (a_get()) return;);
is no longer allowed, but:
eo_do(obj, if (a_get()) something());
is still allowed.
For clarity, this commit only incorporates the Eo changes, and not the
EFL changes to make the efl conform with this change.
Thanks again to Peter de Ridder for triggering this important discussion
which led to this change.
For some reason, they were normal functions instead of eo functions,
which makes them harder to bind, less safe, and just wrong.
This commit fixes that.
This enables checking if an object is being created, or has already been
finalized. This is useful in functions that you want to allow
only during the creation phase (i.e inside the eo_add()).
This function lets you hook at the end of eo_add and override it for a
class. This is essentially the first step towards killing custom
constructors. Instead of having a custom constructor, you should just
do:
eo_add(CLASS, parent, a_set(3), b_set("eou"));
eo_constructor is called at the beginning for pre-init things.
eo_finalize is called at the end, for actually finalizing and doing
things. This cleans up the API and possibly saves a lot of things that
would have been stupid and slow in the past, like loading an elm widget
with an existing theme, and then changing the theme.
** This breaks Eo ABI, please recompile elementary and everything else that
creates eo objects.
@feature
Coverity found the issue, but it's an issue we've already fixed in the
past. I don't know how it got lost, but it seems like someone did a bad
merge. Probably when migrating to Eo2.
This reverts commit 831c20464d.
bug T569 still shows that we have cases where, during e shutdown, we
still get eo_data_scope_get() return NULL for a parent object.
whatever this is, segfaulting is much worse than protecting and
marching on. so protect
This is an extension to raster's 0355a6a296
(eo - fix _parent_set in base clase when old_parent_pd is NULL).
I also added an error message in case this check fails.
This reverts commit ee1b0833ed
I did it manually because the code changed too much.
We actually want this type, it makes things more clear and easier to
understand.
These functions let you pass an array of callbacks instead of just one.
It's more memory efficient to use this if you just add a bulk of events
on the same object.
This commits breaks ABI, and breaks API of the EO_EV_CALLBACK_ADD/DEL
signals (the event info passed).
From now, classes implementing the Eo function with id
EO_BASE_SUB_ID_DBG_INFO_GET will be able to show in Clouseau their own
specific information.
Information contents is controlled by the class itself and no more
by Clouseau. Basic types and lists are supported..
Signed-off-by: Aharon Hillel <a.hillel@samsung.com>
SVN revision: 83410
Tom Hacohen
Carsten Haitzler
Cedric BAIL
Lukasz Stanislawski
Jérémy Zurcher
Cedric Bail
Daniel Zaoui
Daniel Willmann
Aharon Hillel
Vincent Torri