On Aug 6, 2016 12:01 PM, "Felipe Magno de Almeida" < felipe.m.alme...@gmail.com> wrote: > On Sat, Aug 6, 2016 at 7:08 AM, Davide Andreoli <d...@gurumeditation.it> wrote: > > 2016-08-05 18:53 GMT+02:00 Cedric BAIL <cedric.b...@free.fr>: > > > >> Hello, > >> > >> On Thu, Aug 4, 2016 at 8:34 PM, Gustavo Sverzut Barbieri > >> <barbi...@gmail.com> wrote: > >> > I've pushed my WIP to a branch devs/barbieri/ecore-con-eoify, see: > >> > > >> > https://git.enlightenment.org/core/efl.git/commit/?h=devs/ > >> barbieri/ecore-con-eoify&id=35bab5c64a6c928121202697221ecebf4b606659 > >> > > >> > It does compile, but of course doesn't work given the implementation > >> > is mostly stub (and the goal at the moment is only to define the look > >> > & feel of the API). > >> > > >> > As requested by Tom, I've sent an example of usage (just server at the > >> moment): > >> > > >> > https://git.enlightenment.org/core/efl.git/diff/src/ > >> examples/ecore/efl_net_server_tcp.c?h=devs/barbieri/ecore-con-eoify&id= > >> 35bab5c64a6c928121202697221ecebf4b606659 > >> > >> I think your example does illustrate quite well while asynchronous API > >> with events is tricky for users to get right. I think you do set your > >> error handler a little bit to late. What if during finalize the server > >> is unable to listen to that port for whatever reason ? > >> > > > > Cedric I really cannot understand your point here (as I didn't in the > > promise discussion). If something goes wrong inside the constructor > > then eo_add() should return NULL and the user must take care of it.
In the other case I described, when you handle event on an object like image, where you can start a first image loading, then change your mind and do another one, you have to set your event handler before doing anything and you have to track which operation each event is about. Is it the first file set ? The second ? And so on. Basically as Felipe explain below, you don't have a one to one napping if event to operation and you end up doing mistake. > > Are you thinking at some threaded scenario? like something > > can happen between the eo_add() and the callback_add() calls? > > > > Otherwise I cannot see how the gustavo example (with NULL > > check added) can be wrong. > > It doesn't need to be threaded, any of the calls in eo_add could > do a callback for error, for example for trying to bind to a busy > port or no more ports available or even connection dropped or > just some resource not being available (not memory since we > do not care about not available memory errors anyway). Basically what message can the application display when there is no object created ? Using a global eina error is kind of doable, but tricky as you may end up with an operation in between the time the first operation failed and the time you read it that will have changed the real error. > This an intrinsic problem of trying to use events for asynchronous > operations instead of promises. The only way to circumvent it > is using objects to represent operations, then register events > on that and then running the operation, which would be super > verbose to work with. Which sounds really like a promise, but just without the name :-) > [snip] > > >> -- > >> Cedric BAIL > > Regards, > -- > Felipe Magno de Almeida > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
