2017-09-06 10:32 GMT+09:00 Gustavo Sverzut Barbieri <barbi...@gmail.com>:
> On Tue, Sep 5, 2017 at 10:08 PM, Jean-Philippe André <j...@videolan.org>
> wrote:
> > Hi,
> >
> > 2017-09-05 21:57 GMT+09:00 Gustavo Sverzut Barbieri <barbi...@gmail.com
> >:
> >
> >> 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>;
> > }
> > }
> > }
>
> Could... everything else would be the same, except the name would be
> explicitly defined. works for me.
> <https://lists.sourceforge.net/lists/listinfo/enlightenment-devel>
>
Cool :)
This even works today (to a certain extent, at least... no idea how much
info the Eina_Value has about the struct).
--
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
