This commit adds new Eolian API and proper parsing support for struct types.
Structs can be named (allowed in global context, like typedefs, and in typedefs)
and unnamed (allowed as fields of other structs). This extends the existing type
API to support structs. This is incomplete for now - I still gotta add a way to
query global structs besides other things.
@feature
This new API supports function pointer types, multiple type subtypes, const attribute without parsing
the name string, own attribute for any partial type and more. This commit also updates the C and C++
generators so that they compile and generate correct code.
@feature
.eot files are similar to .eo, but they can't contain classes; all .eot files found in include paths
are parsed and information is added into the database. They're there for typedefs and eventually also
enums, structs and constants.
@feature
The function eolian_implement_information_get was returning strings for
the class and the function. It was written in this way at the beginning
because it was not needed to verify the correctness of the class and
the function.
Now that we have the namespace feature, this function must check it,
meaning that the class and the function are now known.
So we can return them instead of returning the strings.
The generators had to find the class from the classname. It is no more
needed.
The C++ generator has been adapted to this new API.
Until now, the functions giving access to class information were taking
the class name as parameter.
Except the fact that we needed to search into a hash table for the internal
class structure, no flexibility is possible.
This change consists in modifying most of the APIs using the class name
with a new Eolian_Class type and adapt the code of the C and C++
generators accordingly.
It includes parser updates, database fill and tests on basic and complex
types.
One can define types in this way:
type Evas_Coord: int; /* Simple type definition */
type List_Objects: Eina_List * <Eo *>;
@feature
Before this change, all the .eo files of the directories given with -I
option were parsed. Most of this information was not necessary at all,
since only the classes belonging to the inheritance of the class given
as parameter were needed.
Now, during the parsing of the given class, the inherits classes are
searched and parsed.
A condition is needed to make it work well. To find a filename for a
class, we consider the lowercase of the class name as the filename we
have to parse.
e.g, Elm_Button -> elm_button -> elm_button.eo
It considerably reduces the generation time.
A fix in the tests was needed.
This patch adds support for protected functions.
In the .eo file, the scope (public by default) has to be added before
the function name e.g:
protected foo ...
To access the protected APIs, #define (CLASS)_PROTECTED is needed e.g:
#define ELM_BUTTON_PROTECTED
When a property needs be defined as virtual pure, its type could not be
given.
It means that, even it was explicit that e.g only the get property if
virtual pure, both (set and get) were considered as virtual pure.
@fix
Now, it is possible to assign a default return value for a
method/property.
It will be used in case the function invocation makes issues, e.g eo_do
failing to find the function...
This tag indicates that the ownership of the parameter/return
value changes.
It is needed by generators (C++/LUA...) to determine if it has to be
freed or not, if it can be used as is or need to be copied...
You can add in the .eo file the eo_prefix:... and data:... in case
you want to override respectively the Eo prefix and the data type.
If "data: null" is used, no data type will be added.