this adds support in eo to generate a reflection API. To get the actaul
reflection to the klass, the API efl_class_reflection_table_set needs to
be called, the table in the end can be generated by eolian. Reflection
API is inherited by the extended class. This means, if you have two
reflection tables, first, the most upperst is called, then the next
lower one is called.
For now this API accepts NULL setter or getter, and will ignore them
silently when they are called.
fix T7681
Differential Revision: https://phab.enlightenment.org/D7879
The next commit will bring support for something like reflection. This
commit prepares the whole tree for getting another argument in
efl_class_functions_set.
ref T7681
Differential Revision: https://phab.enlightenment.org/D7882
This is a safe version of efl_data_scope_get, meaning that it will
return NULL if the object is not of the required type, or if there
is no data for that class, or if the given class was used as an
interface (and isn't a mixin).
@feature
This change lets us remove a field from the structure that leads to
around 20KiB more of saving in private dirty pages in elementary.
This also looks a bit better and feels a bit cleaner.
Breaks API and ABI.
Before this commit, function overrides were explicit. That is, you'd
have to explicitly state you were overriding a function instead of
creating a new one. This made the code a tad more complex, and was also
a bit more annoying to use. This commit removes this extra piece of
information.
This means we now store much less information per function, that will
let us further optimise out structures in the future.
Efl.Object.event_callback_call no longer calls legacy smart callbacks;
calling only event callbacks registered with the given event description
pointer.
Create the method Efl.Object.event_callback_legacy_call to inherit the old
behavior from Efl.Object.event_callback_call, calling both Efl.Object events
and legacy smart callbacks.
Update all other files accordingly in order to still supply legacy
callbacks while they are necessary.
This was never used and there is no plan to ever use it. I'm going to
soon add a different mechanism with which it will be possible to provide
them again to Eo if ever needed without breaking ABI. Though it's
unlikely it will ever be.
Summary:
object_find is more generic, so other mechanisms can also reuse the
code.
The object itself has to support the function, so there is no need for
eo_isa which would have a negative performance impact.
The base class implementation calls interface_get on the parent, so a
override of the function can just call the super function to continue in
the recursion.
Test Plan: just run the eo test suite
Reviewers: raster, tasn, jpeg
Reviewed By: tasn, jpeg
Subscribers: felipealmeida, netstar, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3909
Modify the way hooks are defined and used by promise generation in
Eolian in the Eo API.
Instead of passing macro names as parameters to EO_FUNC_BODY macros,
just re-define the actual hooks when it is needed.
Add two parameters for macros that generate API functions in Eo so
that the generation can be customized with macros used by Eolian.
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Since we cache ops we also need to check function calls work
when we reinit eo, not just class_get functions.
This commit essentially verifies that
5284b62e93 was done correctly.
Mostly unused vars following the removal of eo_do_ret().
However, there are some cases where the migration script got some things
wrong, and I had to manually fix them.
I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
This bug was fixed in d889da6b12, but it was too
late at night to start hacking on extracting a regression test and adding it to
the suite, so adding it now.
This test makes sure that we only fallback to string comparison with legacy
events.
This hasn't been used for a while. Since we are going to break Eo a bit anyway
it's a good opportunity to drop this.
This may cause a slight performance issues with legacy events, such as
smart callbacks. This shouldn't really be a problem as we've migrated away from
them. If it does, we need to migrate the remaining parts. Only relevant
for callbacks that are added before the classes are created, which
shouldn't be possible except for smart, only for old evas callbacks.
This is a convenience macro to be used by the common pattern of getting
a part and then immediately calling functions on it. For example,
without this macro, you'd have to write code like:
Eo *part;
eo_do(obj, part = efl_part_name_get("partname"));
eo_do(part, a_set(7));
while using the helper function trims it to:
eo_do_part(obj, efl_part_name_get("partname"), a_set(7));
@feature
This reverts commit 1714fe93f4.
We actually want this type, it makes things clearer.
Conflicts:
src/tests/eo/function_overrides/function_overrides_inherit2.c
src/tests/eo/function_overrides/function_overrides_simple.c
src/tests/eo/suite/eo_test_class_simple.c
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).
Marcel Hollerbach
Jean-Philippe Andre
Tom Hacohen
Vitor Sousa
Marcel Hollerbach
Felipe Magno de Almeida
Jérémy Zurcher
Vincent Torri