On Mon, 20 Jun 2016 08:10:43 +0930 Simon Lees <sfl...@suse.de> said: > > > On 06/20/2016 07:52 AM, Carsten Haitzler (The Rasterman) wrote: > > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida > > <felipe.m.alme...@gmail.com> said: > > > >> On Sun, Jun 19, 2016 at 9:32 AM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >>> On Sat, 18 Jun 2016 23:06:35 -0300 Felipe Magno de Almeida > >>> <felipe.m.alme...@gmail.com> said: > >> > >> [snip] > >> > >>>> I have explained in the email exactly how they would be translated to C+ > >>>> +, JS and Lua by _not_ being a object used directly by the user > >>>> translated automatically by Eolian. So I don't know what you mean. JS > >>>> will be used > >>> > >>> that is the ONLY way for them to work right. to be translated. have you > >>> looked at c+ promises/futures in stdc++? there is no cancel for starters. > >>> there are wait methods that we just don't support. you CAN'T map an > >>> eina_promise or an eo_promise to c++ promises/futures. they are disjoint > >>> sets. > >> > >> I don't know why you think that's the only way. First of all, if > >> Eolian can generate, > >> why then bindings writing manual code couldn't? > >> > >> I think you're confusing by thinking I have to instantiate a > >> std::future/std::promise > >> for this to be useful and/or used by C++ developers. future/promises are > >> part of the STL, which means Standard _Template_ Library, so the concrete > >> type doesn't have to one from the std:: namespace, I can create one myself > >> and that will be used just the same. This is exactly how all of eina is > >> bound to C++ right now, I do not return a std::list, but a > >> efl::eina::list, which > >> _is_ a list container, i.e. it models the Container concept from the STL, > >> however it has more push_back/insert/etc overloads that also accept > >> a naked-pointer or std::unique_ptr for transferring ownership, and treat > >> value_type as T and not T* (it is like the boost.ptr_container library). > > > > and having an efl::promise and efl::future will miss features from the std > > one's like wait. someone used to the std ones will be confused. as to their > > usage.. someone used to th std ones will not know they can cancel. > > > > the std library isn't the be all and end all of C++, there is really 3 > library’s and they all implement this type of thing in there own way, > one being the std lib, the second being boost and the third being Qt. A
we standardized on std. eina types are mapped to that. we had this discussion long ago. the lstd futures/promises don't map to efl's promises. they are a disjoint set. so either way our promises need to be a different class. > reasonable proportion of C++ programmers don't use the standard library > in there code because it doesn't provide as good implementations as > either Qt or boost. When I was writing C++ we would never use the std > libs we used QStrings and QLists because both provided a significantly > better api then the standard library (I have written command line > applications that depend on the Qt equivalent of eina because its 100x > quicker and easier then using the standard libs. So from this point of > view efl having its own promise class rather then using the standard > libraries with a different api is no big issue. For data types like we have to do it anyway because it doesn't map to std promise/futures. that was my point. if we have to create classes anyway for most languages we may as well just have an efl promise class and make them an object that we completely control the api of across multiple bindings. it then has all the features of the core efl promise and maps 1:1. > lists etc its nice if you can convert from eina ones to std ones but for > something like a promise or a thread concept or anything like that I > don't think its necessary and if you can swap a standard promise for a > efl one at the moment thats a nice bonus but I wouldn't even call it > essential. that's why i said... we just have an efl promise class. then the argument of having to manually bind/map them per language begins to fall apart. just auto bind them like the rest of efl. > -- > > Simon Lees (Simotek) http://simotek.net > > Emergency Update Team keybase.io/simotek > SUSE Linux Adeliade Australia, UTC+9:30 > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
