On Mon, Sep 19, 2016 at 7:33 PM, Cedric BAIL <cedric.b...@free.fr> 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 ?
[...] > 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. +10000 fully agree with Cedric's rationale. Eo's purpose should be solely to serve Efl's use cases, which means asynchronous event driven programming. promise/future should be first-class citizen... as well as iterator and the likes. There is a start already, but refinement is really needed, like returning an iterator<x> should handle warn_unused, free, own... Promise should have its own callback signature, simplified for the user. AND if possible, make eolian or a new tool to handle connections for us, if it was easy to declare objects with composition of events/promises, it would save us lots of typing and errors. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
