On Fri, 14 Jun 2013 13:01:23 -0300 Felipe Magno de Almeida <[email protected]> said:
> On Fri, Jun 14, 2013 at 12:52 PM, Carsten Haitzler > <[email protected]>wrote: > > > On Fri, 14 Jun 2013 11:02:36 -0300 Felipe Magno de Almeida > > <[email protected]> said: > > > > Hello Carsten, > > > > > I'm using metaprogramming in C++ for binding to Eo, but it is proving > > very > > > difficult for lack of void* data parameters for class functions, e.g., > > > class_constructor, > > > class_destructor, constructor. Also, see below. > > > > more details? > > > > I can't right now. But I will do it later today. > > > > > > so ultimately i expect to have this: > > > > > > > > eo_do(obj, > > > > efl_color_set(255, 128, 0, 255), > > > > efl_font_set("Sans", 16), > > > > efl_text_set("This is some text"), > > > > efl_geom_pos_set(20, 30), > > > > efl_visible_set(1)); > > > > > > > > > > Eo as is being used, seems to heavily promote lower case macros. I find > > > this to > > > be very disturbing. I don't know how this could be workedaround, but > > > creating > > > lower-case macros for every function is bound to create difficults with > > > interoperability of third-party code. > > > > i think you are taking the macros too literally - they are lowercase > > because > > they actually represent functions (methods). they won't conflict because > > they > > are namespaced anyway... as much a conflict as a function call of the same > > name > > would be. > > > > With macros I can't define local variables or structs, and with C++ I'm > also restricted well you can define local vars in macros.. but those method macros don't do that. eo uses varargs. so: eo_do(obj, efl_color_set(10, 20, 30, 40)); ACTUALLY is eo_do(obj, EFL_COLOR_SET, 10, 20, 30, 40); the macro just makes the stream of args look function-like thus making it more convenient and pretty... it ALSO happens to so some magic to force typechecking of args too (and since its a macro.. argument count as well). > to member-functions, classes, free-functions, basically identifiers in any > context which would > clash with efl_color_set, efl_font_set, efl_text_set, etc. And, also all > other > function names used in eo but for classes defined by third-party code to > which I may > want to interoperate now or in the future. that's why we namespace them. this is nothing new in c. yes - it affects c++. efl is able to be used from c+ but that comes with the cost of avoiding the namespace - just like everyone in c would have to do. there is no way around this. all the enums, macros, functions and structs - same story. > [snip] > > > Regards, > > -- > > Felipe Magno de Almeida > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > Regards, > -- > Felipe Magno de Almeida > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
