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