2016-06-25 15:54 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>:

> On Sat, 25 Jun 2016 09:08:33 -0300 Felipe Magno de Almeida
> <felipe.m.alme...@gmail.com> said:
>
> > On Fri, Jun 24, 2016 at 7:59 PM, Carsten Haitzler <ras...@rasterman.com>
> > wrote:
> > > On Fri, 24 Jun 2016 07:58:44 -0500 Stephen Houston <
> smhousto...@gmail.com>
> > > said:
> > >
> > >> I would like to add that the theme bugs on Genlist need fixing also.
> Two
> > >> Phab tickets in particular. 1) There is a clipping bug where, a
> Genlist
> > >> large enough to scroll, scrolls out of it's bounds and covers other
> widget.
> > >> The out of bounds content is invisible of course so you don't see it,
> but
> > >> you can still click into it.  2) Genlist tree, the row alternating
> colors
> > >> becomes messed up if a tree items children are created upon expand.
> > >
> > > 1) that's not a theme bug. it's an evas clipping/ object bug of some
> sort.
> > > 2) also not a theme bug but code bug. it just somehow doesnt re-init
> items
> > > with the correct edje group for odd/even.
> > >
> > >> Both of these bugs have Phab tickets.  The eio monitor has a Phab
> ticket as
> > >> well and Cedric is addressing it for the release I believe.
> > >> On Jun 23, 2016 7:35 AM, "Stefan Schmidt" <ste...@osg.samsung.com>
> wrote:
> > >
> > > we have deeper problems. promises.
> > >
> > > right now i'm tempted to just call it quits on promises. remove them.
> do
> > > that stuff with events on objects. i'm tired of the disconnect on
> promises
> > > so drop them entirely. my patience is running thin.
> >
> > Just know we will be either killing the Node.JS bindings or requiring
> > manual code.
> >
> > People will not want to use a binding that will be written like this:
> >
> > download = new efl.net.url_download('http:// ... ');
> > download.on('result', function () { .. });
> > download.on('error', function () { ... });
> > download.on('progress', function () { ... });
> > download.work(); // the async operation
> >
> > This is horrible, people will expect that to work like this:
>
> unless we agree on promises ... yes. they will have to go and we'll have
> the
> above. i will not accept any implementation or solution that makes the c
> api
> harder to use than it needs to be. first and foremost. SECOND it then has
> to
> translate to other languages.
>

Yeah, I totally agree on the SECOND point!
With promise syntax seems you are trying to force other laguages (C,
python, etc)
to match a syntax that is JS only, making all the other uglyer.
In python for example there are no promise concept at all, forcing python
developer to use a .then method don't make ANY SENSE in a pythonic syntax.



>
> since you want to do promise bindings manually, then map it however you
> like
> manually with whatever wrapping etc. but this should not cause the api and
> usage in c to be harder than it needs to be.
>
> > efl.net.url_download('http:// ...').then
> >  (
> >    function (file) // success
> >    {
> >      return x;
> >    },
> >    function (e) // error
> >    {
> >    },
> >    function (p) // progress
> >    {
> >    }
> > ).then( function (x) { ... });
> >
> > This is what we have been advocating since the beginning, and we don't
> > need a huge super Eolian class to have that in all bindings, we just
> > need well defined semantics of asynchronous operations. We can
> > work with Eolian/Eo Promise for that as well and that's all _I_ ask so I
> > can sell EFL idea for other communities as well.
> > However, you wanted to have a super uber promise first and now
> > you just want to drop everything that even remotely  allows us
> > the second syntax.
>
> eh? i want nothing of the sort. there is no reason to make promises as
> complex
> as proposed in c.
>
> > I have to ask, do we even care about bindings or not?
>
> i care, but if we are going to disagree on promises in core efl for much
> longer, then we just have to drop them. yes. people will have to do the
> "obj.on
> ()" stuff. it works. it's better than marching on with promises given the
> extreme disagreements on them and their implementation, api and behaviour.
> js
> didn't have promises for many many many years. we will have to march on
> without
> them if we can't agree on them in the core of efl.
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to