On 28/10/13 22:17, Felipe Magno de Almeida wrote: > Hello all, > > I'm working on an Eo API change for EFL. We're working on top of > Jérémy Zurcher's eo2 branch. > The problem with creating Eo API with the current Eo or with eo2 is > that information about a Eo class becomes inevatibly scattered and > adds a lot of redudancy. For example in eo1 there's the need to write > macros that check the signature, fill Eo_Op_Description array; for eo2 > there's the need to use the EO2_OP_FUNC_* macros to define the API > functions, still fill Eo2_Op_Description array, cast the Private_Data, > etc. > > We needed a way to create Eo classes that had more expressiveness. So > that it becomes possible to read a Eo class and know how many > functions it has, their signatures, etc (this is to create a C++ > binding generated by a tool, I'll get to this later). > > So we started working on a more expressive way to define Eo classes > and we've implemented it. (Still lacks documentation and tests which > are scheduled for november). The new API makes use of two sets of > macros: EO3_DECLARE_* and EO3_DEFINE_*. These macros generate, through > the CPP, the boilerplate code that is required for Eo classes, such as > API functions (those that get called through eo2_do and route to the > correct implementation function), event functions with specific > signatures, etc. > > These macros declare and define the class, respectively, and are meant > to be used in headers and .c files. These macros allow us to have a > good expressiveness for defining Eo classes without moving away from C > and while eliminating a lot of boilerplate code. > > So, one Eo class example using this API: > > ============ > https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo3_simple.h > > #define EO3_SIMPLE_CLASS eo3_simple \ > , constructor(simple_constructor, _constructor, int) \ > , destructor(_destructor) \ > , function(simple_inc, _inc, void) \ > , function(simple_get, _get, int) \ > , function(simple_set, _set, void, int) \ > , function(simple_virtual, _set, void, int) \ > , class_function(simple_class_foo, _class_hello, void, int) \ > , event(simple_set, int) > > ============ > > https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo3_simple.c > > typedef struct > { > int x; > } Private_Data; > > static void _inc(Eo *objid EINA_UNUSED, Private_Data* self) > { > printf("eo3_simple::inc %d->%d\n", self->x, self->x+1); > self->x += 1; > } > static int _get(Eo *objid EINA_UNUSED, Private_Data* self) > { > printf("eo3_simple::get %d\n", self->x); > return self->x; > } > static void _set(Eo *objid, Private_Data* self, int x) > { > eo2_do(objid, simple_set_callback_call(x)); > printf("eo3_simple::set %d\n", x); > self->x = x; > } > // [ other functions ] > > EO3_DEFINE_CLASS(EO3_SIMPLE_CLASS, ((EO3_BASE_CLASS)), Private_Data) > > =========== > > Which compared to eo2: > https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo2_simple.c > https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo2_simple.h > Or eo1: > https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo_simple.c > https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo_simple.h > > Is much easier to use. > > > Now to the C++ binding. This API modification to Eo is meant to make > defining Eo classes expressive enough that a tool can be used to > generate bindings automatically for other languages, specially C++. > > The tool that will generate the C++ binding will read the header files > and with a CPP library it wil hook on EO3_DEFINE_* and EO3_DECLARE_* > to read the class informations. This part of the tool will be written > as a C++ library to be reused for other bindings to get the necessary > information for the EFL API through its headers. > > Eolian is also being developed by JackDanielZ that gives > expressiveness for defining Eo classes by using another language and > tool that generates the headers and C files. The C++ binding > generating tool can easily be made to read both formats to generate > the binding. > > However, I feel that this Eo API modification has its merits for > whoever might want to use C directly to develop in EFL which I think > is a great plus and here I'm advocating that this goes upstream so we > can go forward with a C++ binding for EFL. > > There are other examples of the API in > https://github.com/expertisesolutions/efl/tree/eo3/eo2test . All files > that start with eo3_*. > > Also, we have the examples that specify how the C++ generated binding > tool will output the generated files from this EO API (or the .eo > files) at > https://github.com/expertisesolutions/efl/tree/eo3/eo2test/cxx/generated > with usage samples at > https://github.com/expertisesolutions/efl/tree/eo3/eo2test/cxx/samples > and some utilitary headers at > https://github.com/expertisesolutions/efl/tree/eo3/eo2test/cxx > > Any criticism is appreciated and I'm happy to answer any questions that arise. >
Dear Felipe, Very nice meeting you. Because of the big code dump without documentation/explanations of any sort (examples did help) I'm not entirely sure I got what you were aiming for, but I think I did. Please feel free to correct me as needed. In summary: I didn't like it. Or more correctly, I don't get it, and I don't see the point. Did you look at everyone's complaints about Eo v1 and our motivations for doing Eo v2? If not, please refer to Daniel's and My talk on the EFL dev day. 1. I think eo3_simple.h is significantly uglier than eo2_simple.h. 1.1. It not aesthetically pleasing (looks really bad in the eyes). 1.2. It's very non-C. People can't even start guessing what's going on there. 2. You are exposing private (implementation's static function names) in the headers. 3. Code completion will be broken for all the editors out there. 4. I just don't see any benefit in your changes. We already have a proof of concept for generating C++ code (or more correctly parsing the code for the needed information). Yeah, we require the sources for that, but that's a reasonable request. 4.1. Furthermore, there are better ways to achieve what you are doing in eo3_simple.h. For example have a NOOP (or one that replaces EAPI) macro for tagging objects functions. For example: EOAPI void func(int a); That's easily parseable and you can get all the information from there. Not to mention, Clang will easily work with that. 5. Eolian. I know you've mentioned it, but why don't you use it? It seems to me like a competing efforts instead of a collaboration. Esepcially since that according to them, they already have all the info they need with Eo1 and 2. 6. This code dump really made my life hard. Please be more communicative in the future. 7. Eo.h looks super complicated now. I haven't inspected all the macros because I stopped a step before. I don't like the syntax. However they look overly complicated and include a lot of code duplication from what I've seen. 8. There must be some other implications I haven't even investigated because again, the syntax just doesn't look right to me. If I were you, I would focus into collaborating on Eolian and looking into that, reading about the complaints and lessons we had from Eo1, and consider writing an explanation about Eo3, why it's needed, and what made you choose some of the decisions you've chosen. -- Tom. ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
