On Tue, 12 Apr 2016 13:00:16 +0100 Tom Hacohen <[email protected]> said:

> On 12/04/16 12:56, Carsten Haitzler wrote:
> > On Thu, 31 Mar 2016 16:23:28 +0100 Tom Hacohen <[email protected]> said:
> >
> >> On 28/03/16 08:07, Carsten Haitzler wrote:
> >>> On Mon, 14 Mar 2016 14:07:03 +0900 Carsten Haitzler (The Rasterman)
> >>> <[email protected]> said:
> >>>
> >>>> 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?
> >>>>
> >>>>
> >>>>
> >>>> 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?
> >>>
> >>> so it looks like zero people against this... should we do this now - like
> >>> soon/early?
> >>>
> >>>
> >>
> >>
> >> I've been deferring my reply because I don't really know where I stand
> >> on this. My gut says no, but it is an inconsistency. So no strong
> >> objection from me so far. I'll try to come up with good reasons against
> >> it tonight.
> >
> > that's a loooooong night :)
> >
> 
> I don't have any reasons against it so had nothing to say.
> The only reason I still have is that it feels wrong to me, and that I 
> feel like the object system itself should be differentiated. Though this 
> is an opinion, not a fact.

but as per original arguments. people got confused with evas_xxx vs edje_xxx vs
ecore_xxx vs elm_xxx ... having eo_xxx vs efl_xxx is yet more of this. if we
can remove it, we are better. we should. we are more consistent. :) we are
easier to learn. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [email protected]


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to