On Mon, 9 Dec 2013 21:08:32 +0100 Davide Andreoli <d...@gurumeditation.it> said:
> 2013/12/9 Yakov Goldberg <yako...@samsung.com> > > > On 12/08/2013 01:26 PM, Davide Andreoli wrote: > > > 2013/12/8 Yakov Goldberg <yako...@samsung.com> > > > > > >> So, as soon as "Ragel Strikes Back" > > >> here is " Elm_Image" in Jeremy's format. > > >> http://pastebin.com/xptFf6y0 > > >> > > >> Properties and Methods are as Jeremy described. > > >> And in the end you can also find "implements" and "signals". > > >> > > >> Just one suggestion: lets move "implements" content into "properties" > > >> and "methods": > > >> > > >> methods{ > > >> some_method { > > >> ... > > >> }; > > >> Evas_Smart :: show; > > >> }; > > >> > > >> ...only some comments about properties. > > >> If we want to override , only setter or getter we need to specify "set" > > >> or "get". > > >> If you have better ideas about syntax, please suggest. > > >> properties{ > > >> some_prop { > > >> ... > > >> }; > > >> Evas_Object :: color; > > >> Evas_Object :: size :: set; > > >> Evas_Object :: visibility :: get; > > >> }; > > >> ====================================== > > >> > > >> Some additional question. > > >> Here is some part of ElmFileselector.eo file. > > >> You can see "selected_set" and "selected_get" are described as methods. > > >> Why? Because I generate, this eo file, by parsing descriptions of eo > > >> classes. > > >> If there are two functions which have: > > >> - the same name with "set/get" suffix; > > >> - the same number of parameters; > > >> - all parameters are "in" for "set" > > >> - all parameters are "out" for "get" > > >> it will be described as property; (or "only_set"/"only_get" property) > > >> if one of these rules fails, functions will be generated as methods. > > >> > > >> Because of legacy, "selected_set" func returns, so here I generate it as > > >> method. > > >> > > >> methods { > > >> selected_set { > > >> /*@ Set, programmatically, the currently selected > > file/directory > > >> in the given file selector widget */ > > >> return Eina_Bool; > > >> params { > > >> in const char* path; /*@ */ > > >> }; > > >> }; > > >> selected_get { > > >> /*@ Get the currently selected item's (full) path, in the > > given > > >> file the given file selector widget */ > > >> return const char*; > > >> params { > > >> }; > > >> }; > > >> } > > >> > > >> > > >> But maybe, as soon as it is almost property (only one "ret" gets in > > the > > >> way here), we can describe it as property, which returns some value. > > >> "selected": { > > >> "set": { > > >> "return" : "Eina_Bool", > > >> "comment": "Set, programmatically, the currently selected > > >> file/directory in the given file selector widget" > > >> }, > > >> "get": { > > >> "comment": "Get the currently selected item's (full) path, in > > >> the given file the given file selector widget" > > >> }, > > >> "parameters": [ > > >> { > > >> "path": ["const char*", ""] > > >> } > > >> ] > > >> }, > > >> > > >> We will generate Eo and C - legacy functions as they are now. > > >> eo macro: "selected_set" EO_TYPECHECK (path, const char*) EO_TYPECHECK > > >> (ret, Eina_Bool *) > > >> eo macro: "selected_get" EO_TYPECHECK (path, const char**) > > >> legacy: Eina_Bool elm_fileselector_selected_set(Eo * obj, const char* > > >> path) > > >> legacy: const char * elm_fileselector_selected_get(Eo * obj) > > >> > > >> And C++, python and other bindings will ignore ret in setters/getters > > and > > >> use it as property: > > >> fileselector.path = "/root/some/path/filename" > > >> > > >> > > >> So the question is: > > >> should we treat it like this, or leave it as methods? > > >> > > >> Yakov. > > >> > > >> > > > Hi all, > > > I have one main concern about the generation of bindings using the eo > > file: > > > how we like to manage complex types (see Eina_List) in the target > > language? > > > (python for example) > > > As the py bindings are implemented now (and I really like this!), we do > > not > > > provide bindings for eina types, but we convert to the corresponding > > python > > > type for the user. > > > For example: > > > > > > Elm_Map { > > > { > > > property { > > > overlays { > > > get { > > > /*@ get a list of all the overlays in the map */ > > > }; > > > params { > > > Eina_List overlays; /*@ actually a list of Elm_Map_Overlay > > objs > > > */ > > > }; > > > }; > > > }; > > > }; > > > > > > > > > In this case we don't know what the eina_list "overlays" contain thus we > > > cannot automatically convert to the corresponding python list of object. > > > Other example of complex types I found to be used in the current bindings > > > are C array (usually with strings inside). > > > > > > How can we solve this? > > > we could add the content of the complex type in the eo files: > > > params { > > > Eina_List(Elm_Map_Overlay) overlays; /*@ ...or a different syntax > > */ > > > }; > > > params { > > > Eina_List(char *) names; /*@ ...for an eina list of strings */ > > > }; > > Thanks for comments. > > Looks like it's good idea to do smth like that. But some conversion API > > from > > Elm_Map_Overlay to python object should be implemented. > > > > > > but this can be tricky for more complex types, how we describe a C array > > of > > > strings? > > Could you please give an example, which API does use it? > > > > void elm_calendar_weekdays_names_set (Evas_Object *obj, const char > *weekdays[]) > const char ** elm_calendar_weekdays_names_get (const Evas_Object *obj) > > or > > void > elm_win_available_profiles_set<https://build.enlightenment.org/job/nightly_elm_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/group__Win.html#ga10651320469fa65120e13b184b6ea22f> > (Evas_Object *obj, const char **profiles, unsigned int count) Eina_Bool > elm_win_available_profiles_get<https://build.enlightenment.org/job/nightly_elm_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/group__Win.html#ga7daccafee67b5c68427b3a9ddd56171a> > (Evas_Object *obj, char ***profiles, unsigned int *count) each such use of a c array etc. comes in one of various design patterns. let's just take array: array of pointers with NULL terminator array + size return array of fixed size return array of variable size, but size comes from another api call THEN... the question is.. do you dispose of the array returned? if not - then its an internal, so fine. if you have to dispose, then how (free, a special disposal function etc.). this is an example. reality is that we will use a subset of these above. eo has to be able to declare which "design pattern" it is. (same for returning a linked list or just a generic char * too - is it stringshared or not? const char * vs char *? do you free/stringshare_del it?) bindings to a particular runtime will need to implement helper/generic binding glue code that deals with all the used "patterns". once the pattern is known and declared then eolian can easily choose the correct binding glue code to convert to the "native binding lang" types. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
