Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subject protocol updated in beta5 - replaySubject doesn't currently conform #7

Closed
heckj opened this issue Jul 29, 2019 · 3 comments
Closed

Comments

@heckj
Copy link
Contributor

heckj commented Jul 29, 2019

Wanted to give you a head's up - ReplaySubject no longer conforms to protocol Subject in beta5, as an additional function was added to the protocol. I'm not actively using it, but in pulling in Entwine - master branch - with Xcode, it shows the compilation failure.

@tcldr
Copy link
Owner

tcldr commented Jul 30, 2019

Thanks @heckj ! Have added a temporary fix. Will have a more in depth look when I get a chance. Haven't worked out how it's supposed to handle back pressure yet.

@tcldr
Copy link
Owner

tcldr commented Jul 30, 2019

As far as I can tell, PassthroughSubject sends the subscription it receives via send(subscription:) an unlimited demand and moves along. I've added some tests to master to confirm this behaviour
in ReplaySubject against a control (PassthroughSubject).

I'm interested to see what functionality this api is supposed to enable though, as theoretically a subscription sent via a subject would be shared amongst all its subscribers. So how would these subscribers safely attenuate demand via a shared subscriber? The greediest subscriber will set the pace for all other subscribers.

Potentially it's a glimpse of some testing utilities Apple are assembling – a way of gathering the messages set to a subscription by a downstream subscriber. Maybe thats's what this new Record type is all about.

@tcldr tcldr closed this as completed Jul 30, 2019
@heckj
Copy link
Contributor Author

heckj commented Jul 30, 2019

completely hypothesizing here, but I suspect it’s meant specifically for the variable demand use case. Specifically where a subscriber is taking in data at a specific rate in response to back pressure and wants to vary that rate over the lifetime of available data from the publisher.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants