On Tue, 29 Mar 2016 20:05:10 +0200 Davide Andreoli <[email protected]> said:
> 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 ecore, evas, etc. will go away. it'll just be efl. :) i think you maybe should just have the python bindings remove the double here as python itself adds the efl. prefix at the start and we prefix because in other places that prefix isnt automatically added. :) > > > > >> 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 > -- ------------- 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=278785471&iu=/4140 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
