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
@fix
XXX: Given EFL usage of objects, construction is a perfectly valid thing
to do. we shouldn't complain about it as handling a NULL obj creation is
the job of the caller. a perfect example here is ecore_con and ecore_ipc
where you create a con or ipc obj then set up type/destination/port and
the finalize of the constructor does the actual connect and thus this
fails or succeeds based on if service is there.
until there is a better solution - don't complain here.
This is heavily based on a patch by Vincent Torri. I just refactored it
a bit so it doesn't break ABI on Linux, only on Windows (where it was
broken anyway).
This patch changes things so on Windows, functions are looked up only
based on their name. Because of the indirection (and export/import
tables) windows does, this is the only reasonable way to make it work.
You should always use curly brackets. Especially when the inside statement
has its own curlys. This can be confusing and has already lead to bugs in
many projects.
While unrefing twice works, it's cleaner to unref the ref we
have and delete normally. It will handle parnet detachments in
a nicer way, and is just more correct.
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
As discussed on IRC and ML. We are in a feature freeze phase, and this
patch is not essential. Furthermore, this patch was never discussed.
This reverts commit 537c7fe9e3.
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.
The header.id was masked before using it as index in the _eo_classes
array and was not unmasked when used.
It hasn't caused segfault (by sheer luck) but was wrong.
@fix
So I don't really understand why the code was not there before, but it resulted
in my experiment of making a combobox for elementary just impossible. Now it
work at least.
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.
Now it's more clear and consistent. This commit complements the previous
eo_add commit (a7560dbc61).
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.
Before this change eo_add() used to create an object with 1 ref, and if
the object had a parent, a second ref.
Now, eo_add() always returns an object with 1 ref, and eo_add_ref()
preserves the old behaviour (for bindings).
eo_unref now un-parents if refcount is 0, and eo_del() is an alias for
eo_unref (will change to be a way to ensure an object is dead and goes
to zombie-land even if still refed).
This moves the mainloop check inside the function. There was never need
for it to be in client code (i.e a header/macro).
This is better suited inside eo_do_start because this is a macro some
bindings have to re-implement, and we definitely don't want it to be any
more complicated than it has to be.
This breaks ABI and makes elm 1.12 depend on efl 1.11. This is not an issue
as because of eolian and interfaces it's already the case.
eina_tls_get is really slow, having a fast path for the main loop does really
help us right now. It is also unlikely that slowing down a little bit the use
of eo in thread is going to have any impact on application speed any time soon.
I win a +10% on expedite benchmark compared to without.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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()).
Comp objects are rare, and since we allow using classes as interfaces,
we end up allocating a lot of memory for something we don't even use.
That's why it was a linked list in the first place, and that's why it
should remain a list.
This is almost a complete revert. I reverted the code itself, and the
intent (use of array instead of list), but not the tests, or the new
return value added to comp_detach, which is useful.
This reverts commit ef09ef7489.
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
Match function names when the API pointer is out of range.
Reviewed by TAsn and modified according to his comments :)
Differential Revision: https://phab.enlightenment.org/D876
Tom Hacohen
Carsten Haitzler
Jaehwan Kim
Nicolas Aguirre
Avi Levin
Jérémy Zurcher
Cedric BAIL
Mike Blumenkrantz
Daniel Kolesa
Jean Guyomarc'h
Jean-Philippe Andre
Cedric BAIL
Guillaume Friloux