On Mon, 14 Mar 2016 13:35:04 -0700 Cedric BAIL <[email protected]> said:
> 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. not noew that we have eo 4. there is nothing special about eo vs efl now. it's all: xxx_blahblah(obj,...); if it's eo or it's efl. it's all the same. i dont see code like: o = eo_add(xxx); efl_blah_set(o, ...); eo_ref(o); ... to be nice. we use 2 namespaces to address the same object. > >> 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. we have both api's - we can typedef eina to ... whatever and a sed script can pretty much convert code. :) i'm thinking about NEW users... attracting more rather than worrying about only what we have. > -- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
