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 ! :-)


enlightenment-devel mailing list

Reply via email to