On 29/06/15 17:21, Cedric BAIL wrote:
> On Mon, Jun 29, 2015 at 5:50 PM, Tom Hacohen <t...@osg.samsung.com> wrote:
>> On 29/06/15 15:53, Cedric BAIL wrote:
>>> On Mon, Jun 29, 2015 at 4:18 PM, Tom Hacohen <t...@osg.samsung.com> wrote:
>>>> On 29/06/15 14:32, Cedric BAIL wrote:
>>>>> I think that eo_do_ret and eo_do_super_ret are quite hugly to use and
>>>>> unecessary. I think they should be gone. Their behavior can still be
>>>>> nice to have especially inside efl tree. The reason they exist is that
>>>>> we want to support other compiler than GCC and Clang for application
>>>>> that use EFL. EFL itself can not be compiled by anything else than GCC
>>>>> and Clang.
>>>>>      Maybe we should provide #if piece of code that will enable the old
>>>>> non portable behavior of eo_do and eo_do_super for people who are sure
>>>>> that there code should not be running on something else than GCC and
>>>>> Clang. So if someone want the current behavior of eo_do_ret and
>>>>> eo_do_super_ret, but in a nice way, he will just do a #define EFL_GNU
>>>>> (or whatever we decide) before including Eo.h.
>>>>>
>>>>>      As we are heading to stabilize Eo API in EFL 1.15, I really would
>>>>> prefer to get rid of this _ret variant.
>>>>
>>>> I don't see why this "ret" variant is a problem. We could keep it there,
>>>
>>> It is a very confusing one. You have to pass the variable you want it
>>> to return stuff in. Once you are at the point of needing a variable,
>>> well, ... why do you still need to use eo_do_ret ? Basically useless.
>>
>> It's not useless, it's good for things like:
>> if (eo_do_ret(...))
>> but mostly for things like:
>> if (something)
>> else if (eo_do_ret(...))
>>
>> or
>> if (something && eo_do_ret(...))
>
> You are missing a point here, you always have a useless variable
> anyway in the parameter. So something like :
>
> if (something)
>    {
>       int bob;
>
>       if (eo_do_ret(... bob ...))
>
> Or something like that. Sure you can add this variable at the top of
> your function, but that doesn't reduce how disturbing it is. Why do I
> need a variable ? What does it do ? (That's rethorical question, but
> having to read useless piece of code is lowering the quality of the
> code by creating confusion.
>

I'm not missing the point. I've made my point. The purpose of the 
variable is to work around standard c limitations. We could also get 
around them with gnu extensions. I gave a few examples where it's useful.

>>>> there's no problem with that. It's useful for people want to write
>>>> portable code. For the different eo_do behaviour, we could have a define
>>>> that changes eo_do to the non portable version if we think it's really
>>>> needed. I don't really like the idea, but I don't object. Just offering
>>>> a better way of doing it. :)
>>>
>>> I fail to see the difference with my proposal, but if you are fine
>>> with it, then go.
>>>
>>
>> I'm not fine and not not fine. I wanna see what people say. At the
>> moment, Daniel objects, you are in favour and I'm neutral.
>
> Daniel objects to everything. I didn't answer is mail as there is no
> argument in it. Objecting with no argument is clearly useless to a
> discussion.
>


--
Tom.

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to