Hi all,
As you maybe know, we are developing a tool (Eolian) that will help
people to add functions to the Eo classes and to generate automatically
bindings. We spoke a lot about the .eo format to describe the classes
but we never spoke about the generator. So is the time.
The solution chosen to generate C code is to have two files:
- the first one is fully auto-generated by Eolian and contains EAPI
legacy functions and Eo code
EAPI Eo_Op... = EO_NOOP;
...
EAPI void
evas_object_image_mmap_set(Evas_Object *eo_obj, const Eina_File *f,
const char *key)
{
eo_do(eo_obj, evas_obj_image_mmap_set(f, key));
}
static void
_eo_evas_object_image_mmap_set(Eo *eo_obj, void *_pd, va_list *list)
{
const Eina_File *f = va_arg(*list, const Eina_File *);
const char *key = va_arg(*list, const char*);
_mmap_set(obj, f, key); *// User function located in the second C file*
}
...
static void
_class_constructor(Eo_Class *klass)
{
const Eo_Op_Func_Description func_desc[] = {
EO_OP_FUNC(EO_BASE_ID(EO_BASE_SUB_ID_CONSTRUCTOR), _constructor),
EO_OP_FUNC(EVAS_OBJ_IMAGE_ID(EVAS_OBJ_IMAGE_SUB_ID_MMAP_SET),
_eo_evas_object_image_mmap_set),
...
}
...
- the second file contains the user code. It is not touched by Eolian.
This separation facilitates the generation for the C files. In the
future, when Eo2 is operational, we will be able to switch fast by
invoking Eolian to generate legacy and Eo2.
I think this is the best time to speak about the changes we can make in
the current code to set code conventions:
- Eolian-generated Eo functions have to call user functions. Which
convention for the function name? We decided for the moment to go on the
operation only (_mmap_set).
- Prototypes of user constructor and destructor. Since we are not
supposed to see neither va_list nor parameters (except custom
constructors), we chose to give only the object: static void
_constructor(Eo *obj)...
- Data names are for the moment not following the same style. We have
Evas_Object_Image and Elm_Button_Smart_Data. Since "Smart" comes from
Evas_Object_Smart inheritance, I think it can be removed. On the other
way, Evas_Object_Image is imo not enough specific. We could change these
names to Evas_Image_Data and Elm_Button_Data. Maybe we can change too
Evas_Object_Protected_Data to Evas_Object_Data, since I don't see for
the moment the utility of a possible public/protected/private data type.
I hope that next week, we will show how it will look like on a simple
and little example like ... evas_object_image.c ;-)
JackDanielZ, alias Daniel the 3rd
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
