RACSubject => RACMutableSignal?

[joshaber]

When we talked about renaming RACSubscribable, @jspahrsummers also brought up that RACSubject, too, is terrible but we struggled to come up with a not-awful alternative.

But how about RACMutableSignal? They're mutable in the sense that users can change things about them after they're created, and they tend to be an implementation detail like NSMutableArray vs. NSArray.

The downside is that RACReplayMutableSignal / RACMutableReplaySignal is a pretty ridiculous name.

[joshaber]

Also, I don't think RACSubject is as terrible as RACSubscribable was. I'm pretty ok with it actually. But I'm open to awesomer names if someone has any ideas.

[cwharris]

I'm coming from a .NET background when I say this, but Reactive Extensions for .NET and JavaScript are really taking off, and a lot of .NET developers are beginning to use Rx in live projects.

Personally, I think it'd be easier to understand if both Rx and RAC used similar naming conventions. Everyone familar with Reactive programming knows what a Subject is, and, for that matter, knows what a Behavior Subject is.

I'd agree if you said those nouns don't exactly match the use case for those classes, but won't deviating from pre-existing naming conventions (such as the ones used in Haskell) just create confusion and a bigger learning curve?

[Coneko]

Isn't RACSubscriber the odd one out now that there's no RACSubscribable?
You could call RACSubscriber RACSink and RACSubject RACSource, to keep in line with the signal metaphor, although I don't know of any signal function frp library that uses those names.

[thenikso]

Or RACSignalConsumer and RACSignalSource for subscriber and subject respectively to underline the common area of application. You'd then have RACSignalReplaySource for example.

Overall I believe it's good to move away from the 'er'/'abable' which it's confusing by its own mean.

[jspahrsummers]

I don't feel terrible about RACMutableSignal. I do think it's a bit clearer than RACSubject, but it does lose the common Rx terminology for not that much gain.

The downside is that RACReplayMutableSignal / RACMutableReplaySignal is a pretty ridiculous name.

@joshaber If we did follow a "mutable" naming convention, I would argue that specific mutable signals don't need the "mutable" qualifier in their names. RACReplaySignal inheriting from RACMutableSignal would be akin to NSCountedSet inheriting from NSMutableSet.

Personally, I think it'd be easier to understand if both Rx and RAC used similar naming conventions. Everyone familar with Reactive programming knows what a Subject is, and, for that matter, knows what a Behavior Subject is.

@cwharris I think this is an important point, and I don't want to discount the value of it, but Rx has some pretty ridiculous naming sometimes, which can further obfuscate the already-complex concepts (especially for newbies).

A great example is our recent renaming of RACSubscribable to RACSignal. Certainly breaking from the Rx tradition, but I think the result is much better for anyone who's not familiar specifically with Rx, including developers who are only familiar with general FRP terminology.

I'd agree if you said those nouns don't exactly match the use case for those classes, but won't deviating from pre-existing naming conventions (such as the ones used in Haskell) just create confusion and a bigger learning curve?

@cwharris Related to my prior point, Rx and Haskell often use significantly different terminology, so .NET developers will have a significantly different lexicon from FRP developers. This was part of the motivation for renaming select: to map:, selectMany: to flattenMap:, where: to filter:, etc.

Isn't RACSubscriber the odd one out now that there's no RACSubscribable?

@Coneko I agree that this is pretty odd, but I don't think it's a huge deal. A "subscriber" is an understandable concept, even without any "opposite" term. "Subscribable" is almost meaningless on its own.

You could call RACSubscriber RACSink and RACSubject RACSource, to keep in line with the signal metaphor, although I don't know of any signal function frp library that uses those names.

Or RACSignalConsumer and RACSignalSource for subscriber and subject respectively to underline the common area of application. You'd then have RACSignalReplaySource for example.

@Coneko @thenikso Yeah, I certainly don't want to follow the signal metaphor too far. When we start using signal jargon in place of understandable terms, it only makes things more confusing.

That said, RACSource seems pretty clear on its own merits, and I like how it naturally leads to subclass naming (e.g., RACReplaySource).

I don't like RACSink or RACSignalConsumer as much, in large part because I think the subscribe(r) terminology is fairly well embedded (e.g., subscribeNext:, etc.) and clear on its own.

[joshaber]

You all make great points 👍 ❤️

I'd like to keep the design and naming conventions similar to Rx so long as it makes sense and so long as there isn't an obviously better way. RACSubscribable => RACSignal is, I think, obviously better. I don't think RACSubject => RACMutableSignal is obviously better.

So unless anyone has any objections, I'll close this.

RACSubscriber is definitely bleh, but since users so rarely deal with them directly (usually just use -subscribeNext:...), I'm not terribly motivated to change it until an awesome name pops up.

[cwharris]

As an aside, I'd also like to point out that Rx no longer uses "Subscribables" and "Subscribers", but "Observables" and "Observers", which is somewhat easier to type, and allows for catchy phrases like "composition of observables", and "observe all the things". "Listen to those signals" just doesn't roll of the tongue like "observe these sequences."

IMHO, obviously ^.^

[joshaber]

AFAIK, they never used subscribable/subscriber. I didn't use observable/observer originally because those are already heavily overloaded words in Cocoalandia.

[cwharris]

Makes sense. I'm new to Cocoa, but familiar with Rx. I didn't didn't think they used subscrib-able/er either.

[dannygreg]

I really quite like RACSignalSource or RACSource as it obviously relates it to RACSignal. RACSubject to me has always sounded confusing, as someone who comes from no Rx experience.

[jspahrsummers]

Would anyone here have a strong objection against renaming RACSubject to RACSource?

Is there a compelling argument that it's not worth breaking with Rx terminology for that one (though we already did with RACSignal)?

CC @xpaulbettsx

[joshaber]

I'm not a big fan of RACSource because I think that dilutes the idea that it's also a subscriber. It also makes it sound like all things should emanate out of it, when ideally, you don't use subjects directly that much.

To reiterate, I'm pro moving away from Rx terminology when it's clearly better. I don't think RACSource is.

[anaisbetts]

I always thought Subject was a stupid name. 💯 Subjects really are the "mutable variable" of Rx, so having something to that effect in the name is 🆒

[Coneko]

@joshaber's point is very good. RACSubjects' use as intermediate links in a subscription chain is much more typical of them than the use as sources.

[thenikso]

After reading all this, I got convinced that RACSubscriber is good as it is, if anything to be consistent with -subscribe... methods.

RACSubject is debatable; adding to the argument against changing it, the lack of documentation for RAC could use a "have a look at Rx" for now.

[jspahrsummers]

Putting this into the 1.0 milestone, because we need some hard decision by then.

[joshaber]

👎 Speak now or forever hold your peace.

[jspahrsummers]

RACControllableSignal?
RACManualSignal?

[joshaber]

Those are both meh to me. I'm going to go ahead and close this but we can create a new issue for any new name ideas.