Hi,
2017-09-05 21:57 GMT+09:00 Gustavo Sverzut Barbieri <[email protected]>:
> 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.
>
>
Can't we just declare the struct in EO and use it inside the future<> ?
Like:
struct Future_Struct_Value {
age: int;
sex: bool;
}
class Abc {
methods {
future_do {
return: future<Future_Struct_Value>;
}
}
}
--
Jean-Philippe André
------------------------------------------------------------------------------
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
