On Thu, 12 Dec 2013 16:14:34 +0200 "daniel.za...@samsung.com"
<daniel.za...@samsung.com> said:
> 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.
so the "user" edits the generated file above to fill in
_eo_evas_object_image_mmap_set() for example (eolian generates that function
stub with just enough boilerplate to get them going) right? so it doesnt fully
generate but it also has to update/edit/merge in changes from the eo file. this
generated file #includes the totally "custom user code never touched by eolian"
right? or this eo generated file is NEVER edited by the user and the user has
to write the _mmap_set() func by hand? or does eolian generate these empty
stubs for the user (or update them if params change)? it'd be nice if it could
generate them when they get added to the class with an empty function the
"user" then has to fill. which one is it? i would definitely vote for eolian
generating at least empty stub functions so things compile (and likely dont
work or do anything useful).
for the func name - static so they dont leak out, ensure the "user" file is
#included into the eolian generated file so we keep all symbols local and i'd
say start with _ and add _eoimpl_ (eo implementation) just to ensure it wont
clash with anything else.
static void
_eoimpl_mmap_set(Eo *obj, Eina_File *f, const char *key)
{
}
> 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
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
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
