[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] [EGIT] [core/efl] master 01/02: Eo: Add eo_do_part.
From:       Tom Hacohen <tom () osg ! samsung ! com>
Date:       2015-05-12 15:27:59
Message-ID: 55521BFF.7080300 () osg ! samsung ! com
[Download RAW message or body]

On 09/05/15 12:04, Davide Andreoli wrote:
> 2015-05-08 10:00 GMT+02:00 Tom Hacohen <tom@osg.samsung.com>:
>
>> On 07/05/15 19:35, Davide Andreoli wrote:
>>> 2015-05-07 10:19 GMT+02:00 Tom Hacohen <tom@osg.samsung.com>:
>>>
>>>> On 06/05/15 20:25, Davide Andreoli wrote:
>>>>> 2015-05-06 19:04 GMT+02:00 Tom Hacohen <tom@stosb.com>:
>>>>>
>>>>>> tasn pushed a commit to branch master.
>>>>>>
>>>>>>
>>>>>>
>>>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=6cb22bae35a8e621e0857fc2738657ff068478f8
>>>>>>
>>>>>> commit 6cb22bae35a8e621e0857fc2738657ff068478f8
>>>>>> Author: Tom Hacohen <tom@stosb.com>
>>>>>> Date:   Fri Apr 17 14:31:19 2015 +0100
>>>>>>
>>>>>>        Eo: Add eo_do_part.
>>>>>>
>>>>>>        This is a convenience macro to be used by the common pattern of
>>>> getting
>>>>>>        a part and then immediately calling functions on it. For
>> example,
>>>>>>          without this macro, you'd have to write code like:
>>>>>>
>>>>>>        Eo *part;
>>>>>>        eo_do(obj, part = efl_part_name_get("partname"));
>>>>>>        eo_do(part, a_set(7));
>>>>>>
>>>>>>        while using the helper function trims it to:
>>>>>>
>>>>>>        eo_do_part(obj, efl_part_name_get("partname"), a_set(7));
>>>>>>
>>>>>>        @feature
>>>>>>
>>>>>
>>>>> Is there a reason why efl_part_name_get() is named like this?
>>>>> It seems to me the name for the function is wrong, or confusing at
>>>>> least...
>>>>> *_name_get means: get the name of the part,
>>>>> while the function actually does the contrary. No?
>>>>>
>>>>> And why not just make the macro call the part_get function internally?
>>>>> So that it can be used like:
>>>>> eo_do_part(obj, "partname", a_set(7));
>>>>> This seems much more natural to me
>>>>>
>>>>
>>>> Hey,
>>>>
>>>> efl_part_name_get() is not named like anything. It doesn't exist. This
>>>> part_get feature is an experiment I'd like to see if it picks up.
>>>> However, nothing is using it at the moment.
>>>>
>>>> The problem with eo_do_part() the way you've suggested it, is that it
>>>> limits us to a specific function and a specific number of arguments. I
>>>> see it as something that will be used like:
>>>> eo_do_part(obj, efl_list_first_get(), a_set(7));
>>>> too and many other variations on that.
>>>>
>>>
>>> Ok, now I understand your intention, I was thinking only at edje parts,
>>> as edje is the only place where we use the "part" word.
>>> Maybe then the macro should be called: eo_item_do?
>>>
>>
>> Fair suggestion. I honestly don't know. When I hit the reply button, I
>> was in a "hell yeah, thanks, you are right" mood. Now I'm not sure.
>>
>> Item is very generic while part means you'll be calling this on part of
>> the object. I think part is a stronger word that means what we mean
>> exactly. I'd however love to be convinced otherwise.
>>
>
> ok, go on in this useless discussion :)
>
> I'm also not really sure about the "correct" word, both 'part' and 'item'
> are
> confusing because we use them for specific tasks. We should find
> a word that do not clash with other usage, here some synonyms:
> - component
> - element
> - piece
> - bit
> - chunk
>
> None really seems perfect, but the one I prefer is "element"...
> eo_element_do ??
>


I still think that part is good. Component is also good, but it's too 
long. I think part is better.

> Instead I'm quite sure that the "do" must be at the end,
> ex: eo_part_do, and not eo_do_part

I dunno tbh. It depends on how you look at it. If you consider the do as 
the verb, yeah, it should be at the end. But I don't I consider it as 
the namespace, so for example, we have eo_do and eo_do_super. A 
complement to those would thus be eo_do_part.

--
Tom.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[prev in list] [next in list] [prev in thread] [next in thread]