All classes are allowed, because all classes can be used as interfaces in
order to override behaviour. This is especially needed for mixins and broke
the eo2 tests.
Was fien on the normal path but missing on the error path. Also remove
the spurious break after the return. Would never be reached. Looks like
a copy and paste bug to me.
CID 1187638
This patch sets the one before most significant bit on for classes. This
means that class ids are now very big, compared to the old ids which
were growing small integers (1, 2, 3...).
This makes accidental passing of integers (corrupted obj pointers) less
common.
@feature
as we don't support multiple composites of the same class,
and know at class elaboration how many composites we should have,
we can create the composites array and pack it at the end of the object.
@fix
mixins data offsets are stored in Eo_Extension_Data_Offset[],
if the constructed class is a mixin, do not reserve space for its
private data, the class is in mixins list and will be handled at
Eo_Extension_Data_Offset computation.
see _eo_data_scope_get(...) for private data retrieval
as we don't support multiple composites of the same class,
and know at class elaboration how many composites we should have,
we can create the composites array and pack it at the end of the object.
eo_composite_attach fail if the class of the composite is not
listed in the parent class extensions, or if there is already a
composite of the same class. The later because calls are
forwarded to the first responding composite, see _eo_op_internal().
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.
this is the first step on the road to remove class specific EAPI from Eo.h
using this handle we will know if a Eo* is a class or an object pointer
Conflicts:
src/lib/eo/eo.c
The goal would be to replace the smart children list and friends. The
problem is that they differ in content. Smart children and Eo children are
the same, but Elm children and them differ. If I put this function as a
virtual, it would be possible to override the list of children and if we
start using it in Evas render loop, that could result in "weird" behavior.
I have added the use of a simplified Eina_Trash mempool kind of feature
to have some fast path for allocation if we start using it in Evas render
loop.
Jérémy Zurcher
Tom Hacohen
Stefan Schmidt
Cedric Bail