Replace ColdSignal and HotSignal with SignalProducer and Signal #1655

jspahrsummers · 2014-12-28T21:17:59Z

After the long discussion in #1650, I invited @NachoSoto, @andymatuschak, and @kastiglione to talk more in-depth about the Swift APIs, and specifically where they need improvement.

We had a really, really great brainstorming session, and this is the result. The good news is that we all feel pretty good about this direction, and the bad news is that everything is getting rewritten again.

The important bits are documented on the types themselves, but here’s the handy Quick Start guide of the proposed changes:

HotSignal<T> will be replaced by Signal<T>. Besides the name change, these signals can now send Error and Completed events. This avoids a lot of the lifecycle weirdness that has come up with a value-only HotSignal.
ColdSignal<T> will be replaced by SignalProducer<T>. As the name implies, a signal producer creates Signals (via the start method). You can kind of think of the relationship as something like:
- SignalProducer : Signal :: RACSignal : subscription
- SignalProducer : Signal :: class : instance
Most of the basic operators are written in terms of Signal, but can be lifted to apply to SignalProducer instead.
Operators that benefit from “cold” semantics, like retry and repeat, are written in terms of SignalProducer.

The advantages here are:

The relationship between “hot” and “cold” signals is now much more explicit and well-defined. A “cold” signal (a producer) creates “hot” signals, each of which represents a “subscription” (in RAC 2.x terms).
Many operators only have to be written once, in terms of Signal, and can be lifted to the SignalProducer level.
The semantics and/or difficulties of converting between “hot” and “cold” are more obvious, I think. You don’t need to swap between them on the fly, because they mean different things.
Signal lifetime is now consistent, and completely defined by the event stream. Signal producers don’t do anything special—they really are just value types, and don’t encode any information about lifetime.

I’ll also make some notes in the changes below, to explain more specific things. Please leave feedback if you have it! 🙇

jspahrsummers · 2014-12-28T21:19:01Z

ReactiveCocoa/Swift/Property.swift

+/// A mutable property of type T that allows observation of its changes.
+///
+/// Instances of this class are thread-safe.
+public final class Property<T> {


This is purely a convenience type for binding. It can be implemented entirely in terms of the SignalTemplate.buffer constructor.

jspahrsummers · 2014-12-28T21:27:43Z

jacksonh · 2014-12-28T21:46:06Z

How about SignalGenerator, or SignalBuilder instead of SignalTemplate?

jspahrsummers · 2014-12-28T22:00:46Z

SignalGenerator

@jacksonh GeneratorType already exists in the standard library as a mutable thing that you “exhaust.”

SignalBuilder

@andymatuschak pointed out that the Builder pattern refers to something very specific, and this would not be that.

robb · 2014-12-28T22:02:19Z

I kinda like Task as you mentioned before, as in let task = Template.start() (if I understood you correctly that is)

There are also no RAC 2.0 preconceptions around these names, which could people migrating.

jspahrsummers · 2014-12-28T22:19:45Z

Task is a bit misleading for the “hot” thing, because IMO it implies something that might have methods like cancel() and start(). When you get a Signal, all you can do is observe it—I think the name is fitting.

NachoSoto · 2014-12-28T22:20:26Z

ReactiveCocoa/Swift/Signal.swift

+public func combinePrevious<T>(initial: T)(signal: Signal<T>) -> Signal<(T, T)>
+public func concat<T>(next: Signal<T>)(signal: Signal<T>) -> Signal<T>
+public func delay<T>(interval: NSTimeInterval, onScheduler scheduler: DateScheduler)(signal: Signal<T>) -> Signal<T>
+public func dematerialize<T>(signal: Signal<Event<T>>) -> Signal<T>


👍 no more identity!

jacksonh · 2014-12-28T22:27:11Z

I do think there is a much better name out there than Signal and SignalTemplate. Especially if one of the original stated problems was I wonder if it is doing more harm than good to make ColdSignal and HotSignal sound like almost the same thing.

NachoSoto · 2014-12-28T23:03:00Z

ReactiveCocoa/Swift/SignalTemplate.swift

+	///
+	/// After an `Error` or `Completed` event has been added to the buffer, the
+	/// sink will not add any further events.
+	public static func buffer(capacity: Int) -> (SignalTemplate, SinkOf<Event<T>>)


Looking good. Nice docstring too.

NachoSoto · 2014-12-28T23:09:21Z

I love it! I agree there's probably a better name than SignalTemplate, but except for that I'm really happy with where this is going.

kastiglione · 2014-12-28T23:22:18Z

@jacksonh Another aspect to the name is whether it's natural to be the subject of map, filter, etc. These operators seem to be slightly more fitting of a SignalTemplate than a SignalGenerator or SignalBuilder.

kastiglione · 2014-12-28T23:42:42Z

For some context on the name SignalTemplate. As mentioned above, a number of names were suggested but each with some argument against it. Nearer to the end of the discussion, words like "Blueprint", "Formula", and similar were suggested, at which point I started thinking aloud about how @Coneko pointed out that in RAC 2, a signal network gets assembled as one step, and then once it is subscribed to, many of those signal objects can be discarded because it's the subscription network through which the data flows. I mentioned how I see the signal setup as almost a compilation step, and the data flow the runtime. From that @andymatuschak suggested template, which I presumed was in reference to C++ templates, so it made a lot of sense for me.

A better name would be ideal, but this name seemed to meet criteria that the other names didn't, so it has that going for it.

jspahrsummers · 2014-12-29T00:25:54Z

A few other name ideas (to replace SignalTemplate):

SignalModel
SignalPrototype, PrototypeSignal
SignalDesign

Out of those, I kinda like “prototype” more than “template.”

Tiger6688 · 2014-12-29T01:14:49Z

oh my lady gaga,How about SignalT??

kastiglione · 2014-12-29T02:05:25Z

Prototype has less domain baggage, but also seems less literally correct. I'm 👍 to either.

andymatuschak · 2014-12-29T02:11:04Z

Out of those, I kinda like “prototype” more than “template.”

In prototype-based languages, a "prototype of an X" is itself usable as an "X." That is to say: one could reasonably expect a SignalPrototype to be usable as a Signal. It wouldn't be reasonable to expect a "signal template" to be usable as a signal, though.

This helps type inference, but also just makes the various methods for starting clearer.

jspahrsummers · 2015-01-18T06:27:15Z

ReactiveCocoa/Swift/SignalProducer.swift

+/// Signals started by the returned producer will not send a value until both
+/// inputs have sent at least one value each.
+public func combineLatestWith<T, U>(otherSignalProducer: SignalProducer<U>)(producer: SignalProducer<T>) -> SignalProducer<(T, U)> {
+	return producer.lift(combineLatestWith)(otherSignalProducer)


How freaking awesome is this?

…emplates Conflicts: ReactiveCocoa/Swift/ColdSignal.swift

jspahrsummers · 2015-01-18T07:45:13Z

Trying to implement everything here was a mistake, since we're basically talking about the whole framework. So, instead, I've annotated outstanding TODOs and would like to merge this as-is (and create smaller PRs into swift-development after that).

🙌

jspahrsummers · 2015-01-18T08:49:04Z

Gonna #yolo this so I can create dependencies that don't have crazy diffs.

Replace ColdSignal and HotSignal with SignalProducer and Signal

jspahrsummers added 5 commits December 28, 2014 01:45

Super WIP

8d82132

Finish basic interface sketches

c54a506

Document and export Signal

f1ad990

Document and export SignalTemplate

9c734dd

Document and export Property

8045848

jspahrsummers added this to the 3.0 milestone Dec 28, 2014

jspahrsummers reviewed Dec 28, 2014
View reviewed changes

jspahrsummers changed the title ~~[RFC] Replace ColdSignal and HotSignal with SignalTemplate and Signal (a.k.a. Round and Around We Go)~~ [RFC] Replace ColdSignal and HotSignal with SignalTemplate and Signal Dec 28, 2014

NachoSoto reviewed Dec 28, 2014
View reviewed changes

jspahrsummers mentioned this pull request Dec 29, 2014

[3.0] Question about HotSignal and map #1656

Closed

jspahrsummers added 15 commits January 17, 2015 11:08

Update Objective-C bridge for new types

950d43c

Update FoundationExtensions for new types

221fae7

Fix a bunch of rando compiler errors

2e1155d

Rename start(setUp:) to startWithSignal()

169ea37

This helps type inference, but also just makes the various methods for starting clearer.

Fix bizarre type error within first()

6b9bb29

Implement combineLatestWith()

e0f90ca

Assign Action's executeClosure in init

8f72aa3

Work around versions of <~ broken in the compiler

d44444a

Disable old unit tests

de745b5

Add delay() over signals

1df881c

Add skip() over signals

5b9fa13

Add materialize() and dematerialize()

774e671

Add sampleOn() over signals

8b5d2b1

Add sampleOn() over producers, using binary lift()

8cbffea

Add takeUntil() over signals and producers

a47f03b

jspahrsummers reviewed Jan 18, 2015
View reviewed changes

jspahrsummers mentioned this pull request Jan 18, 2015

++LlamaKit #1681

Closed

jspahrsummers added 3 commits January 17, 2015 23:35

Merge remote-tracking branch 'origin/swift-development' into signal-t…

929338a

…emplates Conflicts: ReactiveCocoa/Swift/ColdSignal.swift

Remove old tests entirely

75faeba

Note TODOs

f81ae5c

jspahrsummers changed the title ~~[RFC] Replace ColdSignal and HotSignal with SignalProducer and Signal~~ Replace ColdSignal and HotSignal with SignalProducer and Signal Jan 18, 2015

Annotate where we're working around missing <~s

480293c

jspahrsummers added a commit that referenced this pull request Jan 18, 2015

Merge pull request #1655 from ReactiveCocoa/signal-templates

12dca98

Replace ColdSignal and HotSignal with SignalProducer and Signal

jspahrsummers merged commit 12dca98 into swift-development Jan 18, 2015

jspahrsummers deleted the signal-templates branch January 18, 2015 08:49

jspahrsummers mentioned this pull request Jan 19, 2015

Thoughts on "The Great Swiftening" after a few hours playing with it #1650

Closed

jspahrsummers mentioned this pull request Feb 9, 2015

Experimental Proposal of rx.Task ReactiveX/RxJava#2641

Closed

eliperkins mentioned this pull request Jun 4, 2015

Presentation jspahrsummers/correct-behavior-through-type-safety#2

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Replace ColdSignal and HotSignal with SignalProducer and Signal #1655

Replace ColdSignal and HotSignal with SignalProducer and Signal #1655

jspahrsummers commented Dec 28, 2014

jspahrsummers Dec 28, 2014

jspahrsummers commented Dec 28, 2014

jacksonh commented Dec 28, 2014

jspahrsummers commented Dec 28, 2014

robb commented Dec 28, 2014

jspahrsummers commented Dec 28, 2014

NachoSoto Dec 28, 2014

jacksonh commented Dec 28, 2014

NachoSoto Dec 28, 2014

andymatuschak Dec 29, 2014

NachoSoto commented Dec 28, 2014

kastiglione commented Dec 28, 2014

kastiglione commented Dec 28, 2014

jspahrsummers commented Dec 29, 2014

Tiger6688 commented Dec 29, 2014

kastiglione commented Dec 29, 2014

andymatuschak commented Dec 29, 2014

jspahrsummers Jan 18, 2015

kastiglione Jan 18, 2015

jspahrsummers commented Jan 18, 2015

jspahrsummers commented Jan 18, 2015

Replace ColdSignal and HotSignal with SignalProducer and Signal #1655

Replace ColdSignal and HotSignal with SignalProducer and Signal #1655

Conversation

jspahrsummers commented Dec 28, 2014

jspahrsummers Dec 28, 2014

Choose a reason for hiding this comment

jspahrsummers commented Dec 28, 2014

jacksonh commented Dec 28, 2014

jspahrsummers commented Dec 28, 2014

robb commented Dec 28, 2014

jspahrsummers commented Dec 28, 2014

NachoSoto Dec 28, 2014

Choose a reason for hiding this comment

jacksonh commented Dec 28, 2014

NachoSoto Dec 28, 2014

Choose a reason for hiding this comment

andymatuschak Dec 29, 2014

Choose a reason for hiding this comment

NachoSoto commented Dec 28, 2014

kastiglione commented Dec 28, 2014

kastiglione commented Dec 28, 2014

jspahrsummers commented Dec 29, 2014

Tiger6688 commented Dec 29, 2014

kastiglione commented Dec 29, 2014

andymatuschak commented Dec 29, 2014

jspahrsummers Jan 18, 2015

Choose a reason for hiding this comment

kastiglione Jan 18, 2015

Choose a reason for hiding this comment

jspahrsummers commented Jan 18, 2015

jspahrsummers commented Jan 18, 2015