On Sun, 08 Dec 2013 11:20:31 +0200 Yakov Goldberg <yako...@samsung.com> said:
> 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? i think i answered that with json format. as to the rest of this thread we need some more keywords like davide was implying. if we return a list.. a list of WHAT? structs ? what struct? list of objects? string (const char *'s) etc.? we also need to indicate allocation/disposal mode with a keyword. ie does the caller need to free() the result or eina_list_free() or call some special free func. what i am thinking here is a delcaration like a typedef - were we can make a keyword and the define the behavior of a return (or even an input paramater. is the input parameter referenced by the object after being passed in or is it only used transiently). this can be even just a macro #define too for eo. so a return might be Eina_List *names; but is that a list of what? so maybe like: Eina_List *names List_Of(const char *); so now we know its a list of const char *. now how do we free it. assume caller doesnt have to free unless indicated. if it does: Eina_List *names List_Of(const char *) Free(eina_string_list_free); for example - ie u have to call eina_string_list_free() on the return value. and it's a list of strings. or Eina_List *objects List_Of(Eo *) Free(eina_list_free); this is much like we use EINA_UNUSED to add attributes to unused params today. it's just adding extra info tags to a return value (or could be used for input values). this would also solve the array issue const char **array Array_Null_Term_Of(const char *) Free(free); that says the array is a NULL terminated array of const char * ptrs. ie. array[] = (0x2343a24, 0x21545f2, NULL }; reality is that in the long term we want to unify our design patterns to work the same way for each case - we just need to indicate what the case is and that's part of the efl class redo. :) > Yakov. > > > > > > ------------------------------------------------------------------------------ > 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 > -- ------------- 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
