2016-09-18 4:30 GMT+02:00 Felipe Magno de Almeida <
felipe.m.alme...@gmail.com>:

> On Sep 17, 2016 3:53 AM, "Davide Andreoli" <d...@gurumeditation.it> wrote:
> >
> > 2016-09-15 8:41 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>:
> >
> > > On Tue, 13 Sep 2016 19:53:20 +0200 Davide Andreoli <
> d...@gurumeditation.it
> > > >
> > > said:
> > >
> > > > I disagree here, really you are saying that only raster use async
> stuff
> > > in
> > > > efl?
> > > >
> > > > >From my POV efl is (and has always been) a fully async toolkit, and
> I
> > > use
> > > > lots of async stuff in all my programs: timers, animators, idlers,
> > > > ecore_con,
> > > > ecore_exe,  ecore_fd, edje_signals, emotion callbacks, etc...
> > > >
> > > > And to be honest I never feel the need for a better async API...
> > >
> > > well long before promises here was my thought:
> > >
> > > we have async in our api by callbacks. we haven't made things as async
> as
> > > they
> > > should be - like file_set or evas images, edje objects etc. with some
> > > returning
> > > true/false for initial success. this was a mistake. for eo we should
> > > basically
> > > indicate success later async (if you care), or have a stop-and-wait api
> if
> > > you
> > > must know now. (obj.wait() ?).
> > >
> > > the real issue is many objects would DO something async and the event
> name
> > > was
> > > different from object to object. ecore-con was different to ecore-ipc
> > > (though
> > > very similar). elm image different to evas image, different to edje
> objects
> > > etc. so you couldnt apply a pattern and just dumbly copy and paste to
> have
> > > your
> > > cb called "when its done".
> > >
> > > so my thoughts were for eo to at least have some core async interfaces
> > > that all
> > > these objects share to do the wait, provide a set of core standard
> events
> > > etc.
> > > - this would reduce the mental load for developers using such api's as
> > > they can
> > > re-apply the same knowledge directly across multiple objects.
> > >
> > > what i liked is the simplicity - just create the obj (image, edje,
> server,
> > > etc.) add event cb's you care about, then "do" the action (set file,
> > > connect
> > > etc.)
> > >
> > > promises do bring in standardization like above, BUT they do it with a
> lot
> > > more
> > > complexity by having another promise object that is created for that
> > > action on
> > > which you then have to listen for the completion or failure etc.
> > >
> > > i understand why technically it has to be this way, BUT it's incredibly
> > > painful
> > > to deal with. i know i'm not the only one using async api's in efl -
> and
> > > they
> > > are not that hard to deal with, but as above, could do with
> improvement.
> > >
> > > i'm dubious about promises still. i see value but i also see downsides.
> i
> > > think
> > > they are such a radical change from what has been proven to work that
> the
> > > WISE
> > > thing to do would be to use them in a limited number of places for now
> and
> > > "see
> > > how that pans out".
> > >
> > > > > Please clarify what would be your proposal in that regard as being
> > > > > against new things without proposing a solution is not helping.
> > > > >
> > > >
> > > > I'm with TAsn, I'm against promise. The simple solution I propose is
> > > > that all the async API have the callbacks explicitly given as params.
> > >
> > > we can't as eolian can't GENERICALLY handle callbacks across languages.
> it
> > > can
> > > only do it for specific special cases - eg event cb's or if you
> manually
> > > bind
> > > api's. this means tht you need to do this the way i suggested above.
> create
> > > obj, add cb's for what you care about, then "do" the action via an api.
> > >
> >
> > This is another key point about the API we are going to design for efl2:
> > are you really sure this is true? really eolian generators cannot handle
> > callbacks in function params?
> >
> > In my experience (python bindings written in Cython and cffi) callbacks
> > are not so difficult to implement, as soon as the callback function is
> > typed and have a *data param.
> >
> > I think we must rethink this hard restriction we are forcing. There are
> > lots of places where callback functions are useful, also outside the
> > async scope we are discussing now, for example:
>
> The problem with callbacks is not difficult to implement, but difficult to
> free the void* data. It needs two function pointers and the void* data to
> implement correctly and generally. Not that I'm against per se, but
> lifetime is the real problem.
>

Indeed the lifetime of the *void data is the trickiest part, a free_data_cb
seems to me the most "correct" way to handle this, not only for bindings
but also for C code.

Can you explain me how promises solve this problem? where the user is
expected to free the *data in C? in both the success/failure callbacks?
What about chained promises?



>
> > elm_object_tooltip_content_cb_set()
> > elm_slider_indicator_format_function_set()
> > elm_entry_markup_filter_append()
> >
> > and more I cannot remember right now.
> > How can we implement those functionality if we don't allow func
> > callbacks?
> >
> >
> >
> >
> > >
> > > > And a note:
> > > > I was trying to keep myself out of this promise discussion, but it
> > > > seems not really possible :)   What I can say is that I will not
> discuss
> > > > about the internal implementation of asyncs/promise, I will only
> argue
> > > > about the API we are going to expose to the user, and I will fight
> > > > for keeping the API as simple as possible.
> > >
> > > the reason i reply to this is, 1. don't keep out of this discussion as
> > > this is
> > > a key core design decision and keeping out just means you'll have to
> live
> > > with
> > > whatever you get - fine if you just don't care. you care. :)
> > >
> > > and you are taking the exact correct approach. think of it from the api
> > > USER's
> > > point of view. for eo+eolian and on we have to consider multiple
> languages
> > > too.
> > > c, c++, js, lua, python (in future)... it has to be sane/nice across
> all of
> > > these. you are coming from the right view here that "think of the user"
> is
> > > key,
> > > not the implementation.
> > >
> > > ...
> > >
> > > so my take is what tasn said - let's TRY promises in SOME areas and
> see,
> > > but
> > > let's not go all-in on them. what "some areas" are is a bit fuzzy
> though...
> > > it'd be good to discuss where we should use promises for now and
> perhaps
> > > have
> > > an alternative way of doing the same thing and see which one people
> > > gravitate
> > > to... then again having 2 ways to do the same thing is confusing
> > > especially to
> > > newbies... :( ARGH!
> > >
> > > --
> > > ------------- 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
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> 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

Reply via email to