[Development] Make a decision for asynchronous APIs

[Sona Kurazyan]

Sorry, that was a typo, I should have written “resumability” , i.e. pause/resume.


Can you also elaborate what do you mean by «reusability»? Ability to do something like future.restart(); ?


1 февр. 2020 г., в 14:44, Sona Kurazyan <sona.kurazyan at qt.io<mailto:sona.kurazyan at qt.io>> написал(а):

In my understanding a future represents a single result of a computation which will be available sometime in future, it doesn’t assume reusability, progress reporting, etc. If you take a look to other implementations of a future (like boost::future, folly::future or std::experimental::future), none of them has this “extra” functionality similar to QFuture, none of them represents a set of results as QFuture does. This may be confusing for people who are expecting QFuture to be a typical future they are used to, and I actually saw some complains about that.

Best regards,
Sona


From: Иван Комиссаров <abbapoh at gmail.com<mailto:abbapoh at gmail.com>>
Sent: Saturday, February 1, 2020 1:56 PM
To: Sona Kurazyan <sona.kurazyan at qt.io<mailto:sona.kurazyan at qt.io>>
Cc: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] Make a decision for asynchronous APIs

Can you please elaborate the difference?



31 янв. 2020 г., в 17:24, Sona Kurazyan <sona.kurazyan at qt.io<mailto:sona.kurazyan at qt.io>> написал(а):

Additionally, there are some discussions about QFuture being a mix between a “Task” and a “Future”. One of the options of improving this situation is to make a QTask (or QJob) out of the current QFuture. But then the question is: should we also support a “classic” QFuture? Is there a value in having it, when there are already some very advanced implementations of a future?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200201/a9364044/attachment.html>