On Jun 22, 2016 18:28, "Carsten Haitzler" <[email protected]> wrote: > 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.
Ah, ok, so as you have likely guessed now, there will be an implementation of wait done by the c++ binding that will do exactly what is expected by c++ developers (and implemented in the way I described above). This is one of the reason to do things manually is to match the language needs and adapt. > 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() Ok, so if that was your concern,I hope that it is now clear that it will work and their is no issue at all with it. Cedric > -- > ------------- 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
