On Fri, 3 Jun 2016 15:42:00 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> said:
here's a rundown of efl promises vs other languages. basically our promises don't match any other languages. we can't just convert them to js promises or c+ + promise+futures... and lua just has NOTHING there in the language. so here is a table: FEATURE | EFL | C++ | JS | LUA | ---------------+-----+-----+-----+-----+ create | X | X | X | | destroy | X | X | X | | then/else | X | X | X | | value | X | X | X | | cancel | X | | | | all | X | | X | | race | X | | X | | progress | X | | | | get status | X | | | | poll value | X | | | | wait | | X | | | wait+timeout | | X | | | ---------------+-----+-----+-----+-----+ c++ futures/promises have features we don't. ti read up and they don't say wait/wait_for/until are optional and may not work. they seem to be requirements. so we can't map promises to c++ futures. it's not possible because we basically break how they work. we can't map them to js because js has no ability to cancel promises. also no progress too. so these features in core api's break then in js. it seems you can't ask if a promise or a future is done yet (without then blocking and waiting) in c++ or js, nor poll/get the value. (fyi in java you can poll the state to see if a future is done yet... for example - java not included above). lua has NOTHING AT ALL to map to. my point is our promises do not map to any existing language promises. not without a broken implementation or control/features missing that are essential. so choices are: 1. we have special efl promises that work LIKE promises/futures in other languages, but they are specific to efl and too bad. that's how it goes. it's the same as mixing different promise libraries for older js implementations and multiple external promise libs for lua etc. that means our promises will never be hand-bound or mapped to existing language ones. it just can't work. see above. or 2. we drop promises and use eo objects to represent an async activity and use event callbacks for async feedback. create some interfaces/classes so we have common events and controls (like cancel, common success/failure/progress events etc.). and then just use these. ... or someone explain to me how we are not broken on various language platforms by not implementing features they have (wait), or how our api/libs will not be just broken by not having controls - like no ability to cancel a promise etc. right now i think we have to do #1. and that means we can't go crazy because we now have new constructs that don't match existing language idioms and people will not be used to them. this does not preclude async operation. it does define HOW you design it though. -- ------------- 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
