On Tue, 20 Sep 2016 01:14:32 -0300 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> 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. well ORIGINALLy my proposal was to have a preprocessor. use it instead of $CC (and use it much like ccache/distcc. set $CC to "eflc gcc" or "eflc clang" etc.) and this preprocessor would basically take c and EXTEND the ability of a preprocessor (like c's cpp) to do better contextual code generation for us and cut out footwork. the good thing is it requires no porting of code. existing c just works. we can then ADD new things and change over time to uise the code/time saving features that simplify our code. so yes - we'd create a hybrid language of c + our own extensions via the preprocessor. but everyone hates the idea so it didnt happen and won't. so give up on this. :) generating c code you then have to edit is far messier as then you have to edit/maintain 2 files - the template file and the generated one in which you put the real code. but thats what everyone wanted. they want the extra work to maintain "purity". :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
