Comments (11)
I think the usage of both is different enough that they can't be the same thing.
Subscribables are built around the idea of being pushed things while lazy sequences are built around resolving things as requested. Those two things seem inherently at odds. I'm not sure there's any way to resolve that without corrupting one or the other.
from reactivecocoa.
I think I agree with that assessment, but they're still conceptually similar enough that I think it makes sense to provide sequences within RAC, and perhaps offer operations that work on either sequences or subscribables.
And, again, subscribables can be modeled as sequences โย not 100% accurately, but closely enough that some sort of adapter could be useful.
from reactivecocoa.
Subscribables model errors and completion, neither of which apply to a general-purpose sequence.
Sequences and Observables from a theoretical perspective, are actually completely equivalent. When you ask for the next item in a Sequence, it could throw an error (in languages that actually have Exceptions, ๐). That's how you'd model errors in a Sequence - and of course, when you ask for the next item, it could say "I don't have anything"; completion.
Now, modeling a async operation completion as a Sequence would of course be silly, since you'd have to park yourself until it completes, but these two concepts really are unified
sending a sequence through a subscribable would require evaluating the entire thing.
Not true, you can return a Subscribable that only upon subscription, evaluates the Sequence. Subscribe is the Rx equivalent of evaluating a Sequence.
from reactivecocoa.
Sequences and Observables from a theoretical perspective, are actually completely equivalent. When you ask for the next item in a Sequence, it could throw an error (in languages that actually have Exceptions, ๐).
Exceptions are an exceptionally (pun intended) poor model for this, because they're not conceptually clean in pure F[R]P. It'd be much cleaner to force everything into an in-band communication stream.
โฆย and of course, when you ask for the next item, it could say "I don't have anything"; completion.
This is more of a ReactiveCocoa-specific problem, but we don't have a way to represent this in a way that doesn't conflict with values already in use. nil
is a perfectly valid "next" value in streams, RACUnit
does other things, etc. If we added this, it'd be a breaking change.
Not true, you can return a Subscribable that only upon subscription, evaluates the Sequence. Subscribe is the Rx equivalent of evaluating a Sequence.
Sure. But that's still evaluating the whole sequence instead of doing it incrementally โย for example, infinite sequences couldn't be modeled as subscribables. So you'd really be saying "only sequences that can be eagerly evaluated can become subscribables."
from reactivecocoa.
So you'd really be saying "only sequences that can be eagerly evaluated can become subscribables."
Not true either :) Though seeing why is a bit more difficult:
IObservable<T> ToObservable(IEnumerable<T> inputSequence)
{
return Observable.Create(subj => {
bool hasUnsubscribed = false;
var enumerator = inputSequence.GetEnumerator();
while(hasUnsubscribed && enumerator.MoveNext()) {
subj.OnNext(enumerator.Value);
}
subj.OnCompleted();
// When they unsubscribe, we'll give up walking the list
return Disposable.Create(() => hasUnsubscribed = true);
});
}
So, if I do something like:
ToObservable(anInfiniteSequence).Take(5).Subscribe(Console.WriteLine);
The Take
will terminate the parent Subscription early. But that infinite sequence is only evaluated on the Subscribe, it's Lazy.
from reactivecocoa.
Interesting. I think @joshaber did something conceptually similar to this for his implementation of generators, but it ended with a lot of race conditions/overworking because disposables aren't as deterministic as they could be.
from reactivecocoa.
Yes, that's exactly what the old generator implementation did. The problem was that the generator could create more values than needed before the disposable was returned and the caller had a chance to terminate it.
from reactivecocoa.
(See https://github.com/github/ReactiveCocoa/blob/18f9cce521fc426ee7945fa6ab64f8b69c0a1ee0/ReactiveCocoaFramework/ReactiveCocoa/RACSubscribable.m#L120 for reference.)
from reactivecocoa.
It seems like the use of backgroundScheduler
would cause issues there. If the generator is synchronous with respect to take:
, wouldn't it terminate appropriately?
from reactivecocoa.
Right, you can make it work but the API is shit.
from reactivecocoa.
I think that's a good argument against generators as such, but it could work more cleanly for sequences. I'll see if I can come up with something interesting.
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.