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?  :)

> > >> 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

Reply via email to