Фьючерсы на цель-C?

Question

Включил ли кто-нибудь Futures в Objective-C? Я (надеюсь, не наивно) полагаю, что должно быть достаточно просто обернуть NSInvocations в хороший API?

Answer 1

Майк Ash реализовал фьючерсы с использованием блоков:

• http://www.mikeash.com/pyblog/friday-qa-2010-02-26-futures.html
• http://www.mikeash.com/pyblog/friday-qa-2010-03-05-compound-futures.html

Answer 2

документация Apple, на blocks in Grand Central Dispatch может представлять интерес.

Answer 3

MPWFoundation имеет фьючерсы на основе Higher Order Messaging:

Предполагая, что у вас есть регулярные вычисления с сообщением computeResult:

result = [someObject computeResult]; 

префиксов, что сообщение с future сообщение будет вычислить результат в фоновом режиме:

result = [[someObject future] computeResult]; 

Объект в result является прокси-сервером, который будет блокировать, когда сообщения отправляются на него до получения значения.

Answer 4

PromiseKit кажется довольно популярным. Там моя Collapsing Futures библиотека. Также есть RXPromise. И еще много.

Некоторые заметки между этими тремя:

• PromiseKit имеет Swift поддержки:
• Каждый из них может быть установлен с помощью CocoaPods.
• Каждый из них автоматически выравнивает значения в два раза в будущем в значениях однократно.
• Каждый из них является потокобезопасным.
• RXPromise и PromiseKit действуют как Promises/A + с JavaScript.
• Они отличаются тем, как управляются фьючерсы. В сворачивающихся фьючерсах есть FutureSource, у которого есть будущее, а не будущее. В RXPromise и PromiseKit будущее - это собственный источник.
• Они отличаются тем, как будущее отменяется. В RXPromise потребитель звонит cancel о самом будущем. В сворачивающихся фьючерсах производитель cancels a token дал метод, который сделал будущее. Я не знаю, что делает PromiseKit.
• Все имеют отличную документацию по каждому методу.

Я склонен к свертыванию фьючерсов, поскольку я написал его и так четко предпочитаю проектные решения, которые он принял. Я считаю, что контроль над контролем является очень важным, поскольку он помогает предотвратить самоподдерживающиеся эталонные циклы (не проблема в JS, но определенно проблема в Obj-C при работе с блоками). Я также думаю, что отменять токены просто упростить. С другой стороны, действовать как хорошо известная спецификация с известного языка было бы очень приятно.