On Thu, 10 Mar 2016 21:51:22 +0900 (KST) Hermet Park <her...@hermet.pe.kr> said:
> IMHO,
> efl_text_set(eo_part(obj, "part"), "text"); is too ugly and
> counterintuitive.
>
> I'm curious how this will be (really) serious in point of total symbol size
> if we support both efl_text_set(), efl_text_part_set()
>
> and
>
> We should assume a scenario how to set a default part with efl_text_part_set
> () API. For instance,
>
> VALUE = {{"default", "xxx"}, {"partA", "AAAA"}, {"partB", "BBBB"}};
>
> for (i = 0; i < 3; i ++) {
> efl_text_part_set(obj, VALUE[i].part, VALUE[i].value);
> }
>
> If so, will the api accept the default name as NULL? or always "default"?
> NULL would be also acceptable than "default"?
well the other alternative was put part name as last arg
efl_text_set(obj, "text", "partname");
and if you don't address a part:
efl_text_set(obj, "text", NULL);
other than the above eo_part and having lots of duplicate funcs (with and
without part)
> -----Original Message-----
> From: "Tom Hacohen"<t...@osg.samsung.com>
> To: "Enlightenment developer
> list"<enlightenment-devel@lists.sourceforge.net>; Cc:
> Sent: 2016-03-09 (수) 00:07:57
> Subject: [E-devel] Eo part - request for comments
>
> 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
> ------------------------------------------------------------------------------
> 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
--
------------- 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
