Hello,

On Mon, Sep 19, 2016 at 03:33:50PM -0700, Cedric BAIL wrote:
> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen <t...@stosb.com> wrote:
> > We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
> > against it.
> 
> There was a thread weeks ago. You indeed didn't take part of that
> discussion, but everyone else involved in that thread was ok. Actually
> the discussion evolved more into a what else to merge in. So their was
> an agreement before this email.
> 
> > Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
> > good thing. This makes our infrastructure easier to test.
> 
> Please define "clean" as it is a bit abstract to me here. What I am
> looking for here is the minimal set of component I need to have
> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
> you could do C without the C library, but would you ?
> 
> I think that your disagreement about merging is only and just because
> you do not want to make asynchronous request a core feature of EFL.
> The rest is mostly rhetoric. Could you please explain why you have so
> much resistance to it being rolled into more place in efl ?
> 
> As for the tests, I really don't like our eo tests. They are not
> really testing a clean scenario that is possible to guess, but just a
> mismatch of everything into one big C file. When something break
> there, you can't just rely on the name of the tests, or reading
> quickly the code to guess what's happening. Nop. You have to get
> hundred of lines of tests with little logical connection to each
> other. I have found them less than useful when developping (And some
> times buggy, as instead of testing a scenario that makes sense, they
> were just testing that the code was matching the tests). So I don't
> get your argument of making it easier to tests.
> 
> > If you mean just compile them together, then there's no point in it.
> > I know why you want to do it, you want to do it because you put Efl.Future
> > inside libeo.so, but the correct thing to do is probably not to put it
> > there.
> 
> I don't want to just compile them together. I want to merge there
> headers. Make it just one library. Make efl.object, efl.future and
> efl.loop one core. Obviously because I want to see efl as providing a
> core asynchronous library with defined pattern. One asynchronous
> pattern is "events", which is like an UDP broadcast (default
> behavior)/multicast (with effort) solution. Efl.Future is more the
> equivalent of a TCP connection. I think providing one without the
> other is going to push for a world of broadcast solution which is not
> always the right pattern. Maybe we should remove events support from
> Eo to avoid this problem.

I have two concerns about merging binarys & headers.

First the binarys, for eo there is EO_DEBUG, which just helped me a lot
finding out a issue where events in eo where not emitted. After speaking
with Tom he told me that EO_DEBUG was meant for compiling eo twice, once
with enabled EO_DEBUG (prints out huge errormessages about missing
leaks etc. or unsorted things which are expected to be sorted), and the
other time without EO_DEBUG, now a library could decide which eo-lib to
load, and so give a user a very easy possiblity to debug eo. With
merging those binary you are adding a huge overhead, since enablding
this EO_DEBUG possibility is now also requireing the other things to be
compiled twice, which would add a overhead. So i would just leave out
what currently is eo.

To the headers, from a POV of someone which needs to learn efl (or wants
to). If you have tiny little units defined by a header and its
implementations, you can learn the codebase quite fast, since eo is not
much of code, but very powerfull and basically used everywhere. So IMO
just leave this eo directory as it is, with its baseclass, and the rest,
its easy to understand like that.
Also in the view of abstraction, eo solves the problem of providing a
OOP solution for c, if you are interested in this solution. IMO timers
are not really part of solving that problem, and thus not really
something which should be merged with ecore.
Also, why not just add a efl header, which basically includes all efl
subsystem headers? so the code gets small, and the view of "we are one
library" is given even if the subsystems are still clearly seperated.

Greetings
   bu5hm4n

> > I need to properly review this list for a more complete reply, but I just
> > wanted to trigger this discussion before you go to sleep.
> 
> You mean, before you go to sleep ? I still have half a day to go ! :-)
> 
> Cheers,
>   Cedric
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to