Remove RACAsyncSubject in favor of RACReplaySubject

[jspahrsummers]

It's not clear what advantage RACAsyncSubject offers over RACReplaySubject. It seems like the latter has a strict superset of the former's behavior. It also seems like a safer default to replay the whole subscribable stream, rather than just the last thing sent.

[joshaber]

Yeah I've wondered about this before...

Note that RACAsyncSubject does behave slightly differently. It only sends the next when it completes, whereas RACReplaySubject sends them as it gets them.

I think the real value is the semantic difference between the two. RACAsyncSubject says you're sending a single value. It's a promise or a future or whatever. Point being it's just one thing. RACReplaySubject says you want to catch up anyone that missed anything, but still act like a stream. I think that difference communicated by different types is valuable.

I'd be interested in getting @xpaulbettsx's thoughts on this.

[anaisbetts]

So, the only difference between them that should be there is that AsyncSubject doesn't replay non-last items - with both of them, until it completes (i.e. when it's still "live"), they both just act like a normal Subject. If you got rid of AsyncSubject it probably would be fine. On .NET, AsyncSubject has some additional secret-sauce to support the await keyword, so it makes more sense that it is a separate class.

[jspahrsummers]

@joshaber The typical use case for RACAsyncSubject seems to be network operations, which I think are absolutely better modeled as a stream, and not as a future.

I think the problem is that RACAsyncSubject is somewhat fragile. If you send more than one value, suddenly the behavior of any subscribers becomes a lot less deterministic. I can't think of a case where I wouldn't want a RACReplaySubject instead.

I think that difference communicated by different types is valuable.

It's worth noting that interfaces typically shouldn't expose whether a RACAsyncSubject or RACReplaySubject is being returned. Callers should just see a RACSubscribable, and how it handles asynchronous behavior is either described in documentation, or an implementation detail.

[joshaber]

Yeah good point 👍

[joshaber]

FWIW, I'm going to do a pass through soon to do some housekeeping. I can remove RACAsyncSubject and RACBehaviorSubject when I do that.

[jspahrsummers]

🤘 Sounds good, though we should keep in mind that RACAsyncSubject got some important concurrency fixes which RACReplaySubject might not have.

[joshaber]

✨ 👍