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.

> 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

Reply via email to