As in the previous commit explained, we want to get rid of class
functions in eo, and make them just c functions right away.
This commit removes the class parameter from the eo_class_function_set
call, and adjusts the tests to not depend on class functions anymore.
Class functions are now not tested anymore, tests that used them as a
way to test *things* are adjusted to test them now with object
functions, tests that just tested the working of class functions are
dropped.
This fixes T7675.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7902
Until this commit eo did class functions as part of the vtable, which
enabled those functions to be overwritten in classes inheriting another
class. However in task T7675 we decided that this is not really good for
bindings, as most OOP languages do not support this sort of feature.
After this commit eolian realizes class function completly outside of
the vtable, the c-symbol that is the class funciton is now just directly
redirecting to a implementation, without the involvement of the vtable.
This also means a change to the syntax created by eo:
Calling before:
class_function(CLASS_A);
Calling after:
class_function();
Implementation before:
class_function(const Eo *obj, void *pd) { ... }
Implementation after:
class_function(void) { ... }
This fixes T7675.
Co-authored-by: lauromauro <lauromoura@expertisesolutions.com.br>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7901
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 commit is a first step in order to add free functions to all the
types that are owned.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7627
Each regular class can now have a section called 'composite',
which can contain interfaces and interfaces only. This defines
a list of interfaces that are allowed to be unimplemented on the
class, as it is assumed the class will be composited with some
other class implementing those interfaces.
Only regular classes can have this, as only regular classes can
be instantiated.
It will also be necessary to check whether the classes in the
section appear somewhere within the inheritance tree. For now,
this testing is not being done.
Example of usage:
composite {
Some.Magic.Interface;
Another.Magic.Interface;
}
directly in the class body.
This introduces a new keyword called required. It only works on mixins.
You can specify a list of regular/abstract classes in there.
Classes specified after the required keyword are later used to verify
the usage of the mixin. With this feature a mixin can define a list of
types that the inheriting object (the object that inherits from a mixin)
needs to fullfill, if one class that is required is not in the
implemented classes, then eolian will bail out.
Differential Revision: https://phab.enlightenment.org/D7584
Summary:
While individual getters and setters are added to the list of methods of
a class, property_def will hold them as a pair.
This will help defining accessors like C#'s where they're grouped.
Also update some eolian-cxx tests that were commented out.
Depends: D7262
Test Plan: run eolian-cxx tests
Reviewers: vitor.sousa, felipealmeida
Reviewed By: vitor.sousa
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7389
This new syntax separates the parent class from extensions, in
a familiar way to similar to e.g. Java. Since changing everything
at once is a lot of effort, implement it alongside for the time
being.
Summary:
This tagging keyword explicitly asks, for bindings that support it,
that the constructor's parameters are added to the class constructor.
Allowing the user to instantiate the class and call the constructor in
a straightforward way.
Reviewers: q66, woohyun, bu5hm4n, Jaehyun_Cho, segfaultxavi
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers, lauromoura
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7221
Summary:
<q66> just remove decl.eo and remove the eolian_decl test; it's useless
<q66> the reason: it used to be testing some specific API, which got replaced with more generalized API that is now used everywhere in the tests, so that specific test no longer has a purpose
resolves some compile errors due to type conflicts
Reviewers: q66
Reviewed By: q66
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6773
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
Because of a typo in generator source (and overlooked error in
tests) we were previously generating incorrect code for setters
with the @auto qualifier. This was brought up in D5306 and is
now fixed.
These types are of questionable value and the API was not entirely
thought out - remove for now, and if a legitimate use is found
later, they may be readded (with a better API), but typically it
seems best to redesign the bad APIs around safe containers...
This is a new type representing a mutable string (no const).
Regular strings cannot be made mutable with @owned because
they might be hidden behind typedefs.
First steps toward explicit function pointer support in eolian.
To declare a function pointer type, use the following syntax, similar to
a regular eolian method declaration.
function FunctionName {
params {
...
}
return: Return type
}
We don't need to keep this in eo files anymore because the APIs
using them are now fully in C. This also allows removal of the
event callback builtin from Eolian.
If you define either the macro MY_CLASS_EXTRA_OPS for normal
methods/properties or MY_CLASS_EXTRA_CLASS_OPS for class methods
or properties, which contains a comma-delimited list of ops defs
(i.e. EFL_OBJECT_OP_FUNC(...), ...) right before including the
generated my_class.eo.c file, the definitions from these will
be included in the actual class. This can be used to override
certain things in a class internally without exposing it to
Eolian, or for testing/debugging.
As there is no need to have separate is_auto, is_empty and
is_pure_virtual for functions and implements (each function has
its own base implement by default) I removed the function ones.
Instead, I added a way to retrieve a function's base implement
so that you can instead do the checks on the implement even when
you only have the function.
I also moved base implement build directly into the parser instead
of the database filler. That allows for significant cleanup. I
also removed distinction of implement pointers in Eolian_Function
for get and set as implements now always contain an entire thing
so the pointer was always the same anyway.
Things should still behave more or less the same, but ordering
of generated functions has changed because ordering of implements
has changed.
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.
Marcel Hollerbach
Daniel Kolesa
Lauro Moura
Felipe Magno de Almeida
Xavi Artigas
Mike Blumenkrantz
Daniel Kolesa
Jean-Philippe Andre
Marcel Hollerbach
Tom Hacohen