With eolian one could declare a future using C++ template-like syntax:
future<int>
That is, a future that provides (resolves to) an integer. With
Eina_Value, this will be an Eina_Value->type == EINA_VALUE_TYPE_INT.
In some cases, when multiple values are needed, it would be written as:
future<int, string>
That is, a future that provides both an integer and a string. In the
old representation one would only get a "void *value", and would need
to do its casts and hope for the best. With Eina_Value, this will be
an Eina_Value->type == EINA_VALUE_TYPE_STRUCT, with internal pointer
being an Eina_Value_Struct, that contains an Eina_Value_Struct_Desc
with the members, memory layout is like:
value = (Eina_Value) {
.type = EINA_VALUE_TYPE_STRUCT,
.value.ptr = &(Eina_Value_Struct){
.desc = EINA_VALUE_STRUCT_DESC_MYSTRUCT,
.memory = &mystruct,
},
};
Easily accessible with:
eina_value_struct_get(value, "member_name", &ret);
Or directly (check/get could be made single-line with a helper function):
// safety first!
if (eina_value_struct_desc_get(&value) == EINA_VALUE_STRUCT_DESC_MYSTRUCT)
{
Eina_Value_Struct st;
eina_value_get(&value, &st);
My_Struct *mst = st.memory;
mst->member_name; // from here on, no more checks are required
}
My proposal is to extend eolian syntax to allow named parameters and
it would generate the structure, typedef and EINA_VALUE_STRUCT_DESC,
all exposed in .eo.h file. Example:
future<age: int, name: string>
Generates: my_class.eo.h
typedef struct _My_Class_Future_Result_Age_Name {
int age;
char *name;
} My_Class_Result_Age_Name;
EOAPI const Eina_Value_Struct_Desc
*EINA_VALUE_STRUCT_DESC_MY_CLASS_FUTURE_RESULT_AGE_NAME;
Generates: my_class.eo.c
static /* not const! */ Eina_Value_Struct_Member
_EINA_VALUE_STRUCT_MEMBERS_MY_CLASS_FUTURE_RESULT_AGE_NAME[] = {
{"age", NULL /* type placeholder */,
offsetof(My_Class_Result_Age_Name, age)},
{"name", NULL /* type placeholder */,
offsetof(My_Class_Result_Age_Name, name)},
};
static const Eina_Value_Struct_Desc
_EINA_VALUE_STRUCT_DESC_MY_CLASS_FUTURE_RESULT_AGE_NAME = {
EINA_VALUE_STRUCT_DESC_VERSION,
NULL, /* ops */
_EINA_VALUE_STRUCT_DESC_MEMBERS_MY_CLASS_FUTURE_RESULT_AGE_NAME,
EINA_C_ARRAY_LENGTH(_EINA_VALUE_STRUCT_MEMBERS_MY_CLASS_FUTURE_RESULT_AGE_NAME),
sizeof(My_Class_Result_Age_Name),
};
EOAPI const Eina_Value_Struct_Desc
*EINA_VALUE_STRUCT_DESC_MY_CLASS_FUTURE_RESULT_AGE_NAME;
// inside class constructor using it:
_class_constructor(...) {
if (_EINA_VALUE_STRUCT_MEMBERS_MY_CLASS_FUTURE_RESULT_AGE_NAME[0].type
== NULL)
{
_EINA_VALUE_STRUCT_MEMBERS_MY_CLASS_FUTURE_RESULT_AGE_NAME[0].type
= EINA_VALUE_TYPE_INT;
_EINA_VALUE_STRUCT_MEMBERS_MY_CLASS_FUTURE_RESULT_AGE_NAME[1].type
= EINA_VALUE_TYPE_STRING;
}
}
The constructor thing is because EINA_VALUE_TYPE_INT and
EINA_VALUE_TYPE_STRING are declared in other libraries, thus cannot be
resolved at compile-time.
Another option is to ignore that from Eolian signature, not allowing
structs there -- one could use future<generic_value>. But as you can
see, to make proper use of structures one need to type a lot, which
could be easily automated by Eolian.
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
