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 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 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. -- 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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
