On 19/09/16 23:33, 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.
Sorry, I missed that thread. What was the topic? > >> 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 ? You are right. Let's merge in Eina too. Or without joking: people have been using Eo without ecore and without Efl.Object. One example is Mike in E (reverted now because Eo was undeclared stable). You'll probably end up using Ecore in the same app, but again, everything you can say here you can say about Eina too. By "clean" I mean "isolated" or "untainted by its users up the stack". (see next comment for more info). > > 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 ? That is exactly the reason (was I hiding it?), but not only, and one example of not "clean". A while back I was giving you some flack for not writing tests for a component of the EFL and cited Eo as an example of getting high test coverage. You then laughed it off and said something in the lines of "it's easier to test because it's smaller and not async" or something like that. **THAT IS EXACTLY MY POINT.** From my experience (and I guess the industry's collective experience), having small separate units make quality assurance easier, units more testable (because you can easily unit test) and the code easier to maintain. > > 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. The Eo suite is a mixture of success-scenario, failure-scenario and regression testing. Success scenario: making sure an expected scenario works. Failure scenario: making sure an expected scenario fails. regression testing: making sure what we have stays the same. Success scenarios would rarely need changing, only if you change something drastic or make the code more strict. Failure would need to change a bit more often, depending on how strict we make the code. Regression testing will probably change often, as they are there so you *understand* that you are changing behaviour, even if undocumented. I'm not aware of any buggy tests, but do let me know if you find one, and while at it, if possible, try and fix them. You have to also remember, these tests have been with us through a few Eo rewrites. They have been here from day 1. :) > >> 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. Of course also merging the headers. What I meant is: you want a cycle dep. Mutual reliance. It's not really a broadcast, because you need to register to listen. Removing events from Eo is not the way to go. If you want an async pattern, do it up the stack (even eolian) and encourage it there. People who use the loop will use it. The same way people use Evas when they want it (not trying to make a funny comment, literally, people include Evas.h when they want to use it). Quite a similar example that reveals better what I mean and see: Let's assume we have a TCP class. You want to add HTTP support to the EFL so you are adding an HTTP class that inherits from it. Now your argument is that you want to merge them because you want to encourage people to use HTTP and not roll their own protocol and arguing that if not that so at least move the port_set (events) function somewhere else. > >> 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 ! :-) > Yeah, before I go to sleep because when I wake up, you'll be asleep. So I wanted it before you went to sleep. -- Tom. ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
