Most of the time you need to retrieve the class from the string
anyway, so remove this relic of old Eolian and gain some small
performance benefits and extra convenience.
Subtly breaks API but everything should be updated.
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.
This allows us to unify retrieval of docs for both regular and
overridden funcs without having two separate APIs. It's currently
missing validation and docgen is still not adjusted properly for
it either, but at least there's this. Enables retrieval of docs
for overridden funcs by default as well.
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.
Previously one API used just virtual (incorrect) and one used
virtual_pure (which just sounds weird). So unify with a single
name, pure_virtual, similar as in other lanugages.
This does not change eo file syntax yet.
Strictness of various Eolian APIs has been enhanced, for example
eolian_class_function_get_by_name now won't return anything if
you request an EOLIAN_PROPERTY and the found func is just an
EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs
like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will
need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD
explicitly.
The purpose of this is to reduce potential bugs and fix ambiguous
behavior. Thanks to use of EINA_SAFETY, appropriate errors should
be printed into terminal when an API is used incorrectly.
Marcel Hollerbach
Daniel Kolesa
Jean-Philippe Andre
Vincent Torri
Lauro Moura
Gustavo Sverzut Barbieri