Thinking of the Future

55 views
Skip to first unread message

Rob Napier

unread,
Oct 6, 2014, 3:26:39 PM10/6/14
to llam...@googlegroups.com, justin.sp...@gmail.com
So now that I've pulled Future out, I'm thinking about how and where to put it back in.

(I know this message is a little disjointed; I'm at the "asking for opinions" stage more than the "here's what I'm doing" stage.)

Justin, is there a lowest-common-denominator Future that RxCocoa would want? Or is it better to keep it in a LlamaFuture module? Is it problematic to put Future in LlamaCore, noting that you can import individual types to avoid contamination (I don't know how well that works in practice).

To that end, I haven't yet figured out how to have multiple modules in a way that is convenient to consume. Has anyone really tried that. My current design of Future doesn't itself rely on anything (not even Result). My current thinking was to make Future<Result> be wrapped in something else, called Task (based on the scalaz-concurrent naming). I'm open to other good inspirations beyond Scala and scalaz-concurrent that fit cleanly into Swift and Result.

So starting the thread. I have a working impl here that should be considered baseline. I'm looking for comments:



I still have hanging out there the idea of a Promise, which is a manually completable Future (or possibly a Task). I separate Future from Promise because "future things" that represent computations are very different from "future things" that you are going to put your own value into.




Justin Spahr-Summers

unread,
Oct 7, 2014, 12:55:45 AM10/7/14
to Rob Napier, llam...@googlegroups.com, Josh Abernathy, Rob Rix
CCing Josh Abernathy (the original RAC author) and Rob Rix (who files 80% of Swift radars) in case they have thoughts, although I think external posting to this list is disabled.

For context: this thread is about the inclusion of a common future/promise/task type into LlamaKit, a very fundamental library upon which RAC 3.0 is already based.

On 2014-10-06, at 12:26, Rob Napier <robn...@gmail.com> wrote:

So now that I've pulled Future out, I'm thinking about how and where to put it back in.

(I know this message is a little disjointed; I'm at the "asking for opinions" stage more than the "here's what I'm doing" stage.)

Justin, is there a lowest-common-denominator Future that RxCocoa would want?


This is effectively a stripped down stream type. It can use all of the same primitives available for the other types in the library, and explicitly builds upon/extends them.

I guess we always could restructure that arrangement to use an external future implementation, but what would be the benefit? Are we expecting a lot of third-party libraries to expose a futures-based interface?

Or is it better to keep it in a LlamaFuture module? Is it problematic to put Future in LlamaCore, noting that you can import individual types to avoid contamination (I don't know how well that works in practice).

If RAC continues to have its own type, including a Future in LlamaCore would be highly unfortunate. Even if we can avoid it easily enough, it’s super confusing to consumers.

But I am open to being convinced that RAC should use a common future—I mostly just want to understand the arguments for including it in a common library.

To that end, I haven't yet figured out how to have multiple modules in a way that is convenient to consume. Has anyone really tried that. My current design of Future doesn't itself rely on anything (not even Result). My current thinking was to make Future<Result> be wrapped in something else, called Task (based on the scalaz-concurrent naming). I'm open to other good inspirations beyond Scala and scalaz-concurrent that fit cleanly into Swift and Result.

So starting the thread. I have a working impl here that should be considered baseline. I'm looking for comments:



I still have hanging out there the idea of a Promise, which is a manually completable Future (or possibly a Task). I separate Future from Promise because "future things" that represent computations are very different from "future things" that you are going to put your own value into.


I disagree with some of this taxonomy, but I’ll avoid getting into it unless RAC is going to adopt a LlamaKit type for this. :P

Thanks,
Justin
Reply all
Reply to author
Forward
0 new messages