On Wed, 22 Jun 2016 10:31:54 -0700 Cedric BAIL <[email protected]> said:
> On Tue, Jun 21, 2016 at 10:35 PM, Carsten Haitzler <[email protected]> > wrote: > > On Mon, 20 Jun 2016 13:03:01 -0700 Cedric BAIL <[email protected]> said: > >> On Sun, Jun 19, 2016 at 9:38 PM, Carsten Haitzler <[email protected]> > >> wrote: > >> > On Mon, 20 Jun 2016 00:35:35 -0300 Felipe Magno de Almeida > >> > <[email protected]> said: > >> >> On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler > >> >> <[email protected]> wrote: > >> >> > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida > >> >> > <[email protected]> said: > >> >> > > >> >> >> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler > >> >> >> <[email protected]> wrote: > >> >> >> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida > >> >> >> > <[email protected]> said: > >> >> > >> >> [snip] > >> >> > >> >> >> There will be wait. I'll implement it. It will throw an exception if > >> >> >> it is called from the mainloop thread. And people will miss cancel > >> >> >> if they don't look for it. They will miss it too if they use > >> >> >> Eo_Promise too and don't look for it. > >> >> > > >> >> > there';s a difference. if it's a std promise then they expect it to > >> >> > work a certain way. if its an efl one they need to learn its api and > >> >> > behaviour. they will find the features. > >> >> > >> >> We can't be arguing C++ API because users won't read a header file. > >> >> This is not reasonable. Do we expect C developers to read > >> >> documentation, or at least doxygen docs? > >> > > >> > we do expect them to read. though in my experience few actually read a > >> > header file. docs is an expectation. > >> > > >> > but the issue here is of masquerading with a feature that will never work > >> > (wait). it'll always cause an exception. it'd just be best to look > >> > similar to a future/promise and just be a different class. > >> > >> I don't understand why you think we can't implement wait. The C++ > >> standard doesn't expect it to work with a mainloop, but from another > >> thread. So it is very simple to implement it. When you instanciate a > >> promise, you do also create a mutex, a cond and add a first > >> then/cancel couple that will just take that mutex, set the value and > >> broadcast on the cond. The future itself when instanciated will ref > >> count the promise and on the wait will take the mutex and wait on the > >> cond if the value is not there already. The only difference is that > >> use of wait in C++ will lead to dead lock if you use it in the same > >> thread, we will have a warning and throw an excepion in that case. > >> This is the only difference and I fail to see where you see a problem. > > > > we have no wait in efl for promises. that's my point. it doesn't exist. and > > yes > > - if it were to be used within the same thread where the work is done - it'd > > deadlock. > > Yes, we don't have one and it would only make sense to have one, when > we push for having more thread around, for now it can wait. And if it > is possible to implement it in the C++ binding, it should be possible > in C when the need come. I still don't get why you are making that > point. The C++ binding as any binding on promise is manually done for > reason discussed in other email here, so the fact that we do not have > a 1:1 matching doesn't matter as long as we can provide what the user > of that language expect, which we can. my point is that if you want to have promises mapped natively to each language by hand, then c++ has a wait() and nothing maps to that at all and so you have a wait() that does nothing. c++ devs used to promises/futures in c++ will be confused when a feature they expect to work does not. the point of mapping to the native language type for this is to re-use existing knowledge. the existing knowledge doesnt map. it fails e.g. with wait() -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
