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? > what do you guys think? > > regards > davemds > > > > >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> > ------------------------------------------------------------------------------ > 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 >
------------------------------------------------------------------------------ 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
