ReactiveCocoa/ReactiveCocoa — pull request #1532 by jspahrsummers (2014-10-16 06:18:36+00:00)
Title: [WIP] Refocus the Swift API on hot vs. cold instead of Behaviors vs. Events

**:construction: WORK IN PROGRESS :construction:**

_Depends on #1531._

I was recently using the [RAC.Swift](https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1382) API in anger for the first time, and—to put it delicately—it sucked. It was super hard and complex to do anything, and didn't _make my code better_. In short, nothing remained of the RAC that I loved to use.

I went back to [the drawing board](https://gist.github.com/jspahrsummers/00d1ad24afbe26cd7abe), and realized why the APIs had turned out so badly. By separating signals into always-hot [Behaviors](http://hackage.haskell.org/package/reactive-banana-0.8.0.2/docs/Reactive-Banana-Combinators.html#t:Behavior) (represented by the `Signal` type) and always-cold [Events](http://hackage.haskell.org/package/reactive-banana-0.8.0.2/docs/Reactive-Banana-Combinators.html#t:Event) (represented by the `Producer` type), anything that could involve _cold_ Behaviors or _hot_ Events quickly became a nightmare.

After discussing the matter with @joshaber and @joshvera, we agreed that since Behaviors can be represented more-or-less completely by Events, it wasn't really worth surfacing that distinction in our API. Instead, we need to focus upon what was the original goal of 3.0 (even before Swift): making the hot vs. cold distinction explicit and simpler.

So, this :fires: the previous `Producer` and `Signal` types, and adds `ColdSignal` and `HotSignal` (names very subject to change) in their place. There's still a lot of implementation work to do, but the branch temporarily includes [a sketch](https://github.com/ReactiveCocoa/ReactiveCocoa/blob/193bfebb5045cc2555d16e79d7bc9ed383bdab52/ReactiveCocoa/gistfile1.swift) of what I have in mind for the finished product.

Comments appreciated! :bow:

/cc @andymatuschak

**To do:**

- [ ] Clean up `TODO`s and `FIXME`s introduced by this refactoring
- [ ] Add most of the basic operators that are planned
- [ ] Update those few unit tests that already exist