On Mon, Mar 14, 2016 at 7:27 AM, Felipe Magno de Almeida
<[email protected]> wrote:
> On Mon, Mar 14, 2016 at 2:07 AM, Carsten Haitzler <[email protected]> 
> wrote:
>> so now eo api and efl look the same... work the same. why keep eo api as eo_ 
>> ?
>> why not just move it into efl_ space :) i see no reason to keep it separate.
>> it's just confusing. is what iw ant in eo_ or in efl_ ?
>>
>> either that or we move all efl_* space to eo_* - either way .. why keep both?
>> why make people have to figure out where something comes from before they can
>> use it?

You have my support for this. Nobody reacted possitively when I
proposed that, but I don't see the point of the eo namespace in efl
interface.

>> now that comes to eina. we can't sensibly do eina_* to efl_* i think without
>> having major issues. but what do people think? maybe it should be less
>> mysteriously named like eina_and instead be et_ or edt_ (efl types, efl data
>> types)... unless we can sensibly actually make it efl_...
>>
>> i am not talking about what .so is belongs in - just the api namespacing.
>>
>> comments?
>
> For Eina, wouldn't that mean double the symbols for legacy?

Also this is going to be a tremendous change with no clear benefit as
it only affect our C user. It is going to create a massive confusion
as there will be even less code showing it. Also I believe that by now
our C developers base is used to it and will have some pain to do that
change risking to loose developers for no reason.
-- 
Cedric BAIL

------------------------------------------------------------------------------
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=278785231&iu=/4140
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to