Hey, As casually mentioned a while back, and as I put in the wiki page (https://phab.enlightenment.org/w/eo/), we came up with an idea called eo_part().
Introduction to the problem: We have a "part" type in many places in our API. Consider for example the eolian property Efl.Text.text_part, at the moment we'll generate: efl_text_part_set(obj, "part", "text"); This is very annoying to use because in most cases it'll actually be efl_text_part_set(obj, NULL, "text"); Generating two variations for each function (one that accepts a part and one that assumes null) is ugly and will create twice as many symbols, which is bad. In order to solve that, we came up with an alternative. We will only generate one variation efl_text_set(obj, "text"), and if you want to set the part, the syntax becomes: efl_text_set(eo_part(obj, "part"), "text"); which is similar to how we do eo_do. An example to how that would look is already available in the eolian wiki page (https://phab.enlightenment.org/w/eolian/), namely the part that looks like: "@property some_text @part {".. The implementation function will look the same and will get the following parameter: "const char *part" automatically, whether eo_part was called, or not (the NULL is passed). So from the implementation side it looks exactly like efl_text_part_set. We could make it general purpose, but that means using "void *", which means we lose type checking capabilities, so the idea is to limit part to only be const char * to avoid any confusion with types. To summarise, what I would like to know: 1. What do you think about limiting only to const char *part. Can you think of any reasonable cases where part can be non string? Will we actually use those cases? 2. Do you hate the idea/have a better one? 3. Any other comments? Thanks, Tom. ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
