On Tue, 8 Mar 2016 15:07:57 +0000 Tom Hacohen <t...@osg.samsung.com> said:
> 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? what does eo_part() return - it has to return a real eo object. this requires all objects that have parts to maintain real eo objects representing parts. : ( this is not really great if we want to reduce memory usage and do things like keep number of objects low or even non-existent. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel