Comments (19)
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.
from reactivecocoa.
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?
from reactivecocoa.
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.
from reactivecocoa.
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.
from reactivecocoa.
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 noRACSubscribable
?
@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
andRACSubject
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
andRACSignalSource
for subscriber and subject respectively to underline the common area of application. You'd then haveRACSignalReplaySource
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.
from reactivecocoa.
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.
from reactivecocoa.
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 ^.^
from reactivecocoa.
AFAIK, they never used subscribable/subscriber. I didn't use observable/observer originally because those are already heavily overloaded words in Cocoalandia.
from reactivecocoa.
Makes sense. I'm new to Cocoa, but familiar with Rx. I didn't didn't think they used subscrib-able/er either.
from reactivecocoa.
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.
from reactivecocoa.
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
from reactivecocoa.
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.
from reactivecocoa.
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 🆒
from reactivecocoa.
@joshaber's point is very good. RACSubject
s' use as intermediate links in a subscription chain is much more typical of them than the use as sources.
from reactivecocoa.
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.
from reactivecocoa.
Putting this into the 1.0 milestone, because we need some hard decision by then.
from reactivecocoa.
👎 Speak now or forever hold your peace.
from reactivecocoa.
RACControllableSignal
?
RACManualSignal
?
from reactivecocoa.
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.
from reactivecocoa.
Related Issues (20)
- [SwiftPM on Xcode] Package resolution failed HOT 2
- Unable to compile targeting macOS Catalyst using SwiftPM (fix exists)
- why RACObserve(self.scoreStepper,value) not available? HOT 1
- App rejected for HealthKit metadata HOT 4
- UISearchBar delegate proxy crash on Mac Catalyst HOT 1
- Build error when using ReactiveCocoa via Swift Package Manager HOT 3
- can not deinit HOT 2
- Xcode12 ReactiveObj archive error HOT 3
- How to implement PIN input with attempts HOT 1
- Dispose SignalProducer created via Action HOT 1
- UnsafeKVOProperty initializer crashes after updating to ReactiveSwift 6.5.0 HOT 1
- EXC_BAD_ACCESS Cash with NSURL HOT 1
- ReactiveCocoa 11.1.0 incompatible with ReactiveSwift 6.6.0 HOT 5
- Xcode 12.5 beta 3 can't build ReactiveCocoa with SwiftPM. HOT 2
- Using "<~" binding function with Signal.Observers causes memory leaks. HOT 1
- Upgrading from very old version (2.5) fails - can't find ReactiveCocoa.h HOT 1
- Cannot remove an observer <RACKVOProxy 0x280264940> for the key path "unit" from <HGConfigureModel 0x280d25050> because it is not registered as an observer.
- Current version can't be compiled with the latest ReactiveSwift version HOT 2
- Current version can't be compiled with the latest ReactiveSwift version HOT 6
- Add output values support for interception
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from reactivecocoa.