On Wed, 30 Mar 2016 20:38:31 +0200 Davide Andreoli <[email protected]> said:
> 2016-03-30 6:56 GMT+02:00 Carsten Haitzler <[email protected]>: > > > 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. :) > > > > if everything will be child of "efl." than there will be no problem at all that is the goal - ans its one reason i say - lets nuke the exception that is eo_* ok - we have other libs that have no eo based api yet - eventually they will or be wrapped (or just always be an internal efl detail not to exist as an external api). > > > > > > >> 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 > -- ------------- 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
