On 10/03/16 15:54, Tom Hacohen wrote:
> On 10/03/16 12:51, Hermet Park wrote:
>> 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"?
>
> That is a another alternative, and to be honest, not a bad one.
> Duplicating. At the moment we have a total of ~20 functions that use the
> "keys" eolian directive (part candidates), and I suspect it'll actually
> become less with interfaces. I wonder if maybe duplicating is in fact
> the best idea. To me it sounds like the cleanest solution.
Correction: there are actually a few more because the previous count
didn't include methods, only properties. So the previous ones are
probably ~40 (double because of set + get for properties) + ~40 for the
methods. I guess we end up with 80 relevant functions that could be
extended (maybe for some of them it doesn't make sense not to pass a
part), so around 80 extra symbols. Doesn't sound too bad.
--
Tom.
------------------------------------------------------------------------------
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
