On 20/09/16 05:14, Gustavo Sverzut Barbieri wrote: > 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.
I'll reply to cedric in a moment, but in the meanwhile: > > 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. > They can, be, but they will just be provided by Eo. There's no need for any special treatment in Eo. Promise signature: you don't need to do it in Eo. I mean, you can add a special type in Eolian, but Eo itself need not be aware. Also, I disagree. > 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. > > I'm not sure what you meant here. -- Tom ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
