2016-03-16 12:54 GMT+01:00 Amitesh Singh <[email protected]>: > On Mar 15, 2016 8:00 AM, "Carsten Haitzler" <[email protected]> wrote: > > > > 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. > > > > I agree with raster on this. It's not that nice to use 2 namespaces to > address same object. > Efl_object _ add seems nice to me. Any takers? :) >
hmm, I'm facing an issue right now that is related to this discussion, (me working on eolian generated python bindings) in current python-efl the user use the efl libs as: from efl import elm bt = elm.Button(...) so the button is namespaced as: efl.elm.Button (efl is the main package) Now the new efl interfaces will become namspaced as: efl.efl.gfx.Base obviously the double efl at the start isn't so good and is quite confusing.... So the problem here is that we have a namespace (efl) that is the same as the project name.... in a tree: - *efl* --- ecore --- evas --- *efl* ------gfx To conclude: my vote goes to fully remove the Efl_ namespace in favor of the Eo_ one. regards > > > >> 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 > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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=278785471&iu=/4140 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
