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

Move more methods into <RACStream> #135

Merged
merged 25 commits into from Nov 28, 2012
Merged

Move more methods into <RACStream> #135

merged 25 commits into from Nov 28, 2012

Conversation

jspahrsummers
Copy link
Member

No description provided.

@jspahrsummers
Copy link
Member Author

I mostly wanted to open this early because the takeWhileBlock: and takeUntilBlock: tests are failing for <RACSignal> (but not RACSequence). The take isn't properly being terminated early, so it ends up more like a filter.

With some debug logging added to bind::

Test Case '-[RACSignalSpec _RACStream__taking_with_a_predicate_should_take_until_a_predicate_is_true]' started.
  <RACStream> taking with a predicate should take until a predicate is true
2012-11-25 16:42:15.524 otest-x86_64[68214:707] <RACSignal: 0x7fafb3a03020> name: (null) got signal <RACSignal: 0x7fafb3a04690> name: (null) from bound value 0
2012-11-25 16:42:15.524 otest-x86_64[68214:707] <RACSignal: 0x7fafb3a03020> name: (null) got signal <RACSignal: 0x7fafb0e454b0> name: (null) from bound value 1
2012-11-25 16:42:15.525 otest-x86_64[68214:707] <RACSignal: 0x7fafb3a03020> name: (null) got signal <RACSignal: 0x7fafb1d01b90> name: (null) from bound value 2
2012-11-25 16:42:15.525 otest-x86_64[68214:707] <RACSignal: 0x7fafb3a03020> name: (null) got signal (null) from bound value 3
2012-11-25 16:42:15.526 otest-x86_64[68214:707] <RACSignal: 0x7fafb3a03020> name: (null) disposing (null) after bound value 3
2012-11-25 16:42:15.526 otest-x86_64[68214:707] <RACSignal: 0x7fafb3a03020> name: (null) got signal <RACSignal: 0x7fafb1b486d0> name: (null) from bound value 0
2012-11-25 16:42:15.526 otest-x86_64[68214:707] <RACSignal: 0x7fafb3a03020> name: (null) got signal <RACSignal: 0x7fafb1b44ec0> name: (null) from bound value 2
2012-11-25 16:42:15.527 otest-x86_64[68214:707] <RACSignal: 0x7fafb3a03020> name: (null) got signal (null) from bound value 4
2012-11-25 16:42:15.527 otest-x86_64[68214:707] <RACSignal: 0x7fafb3a03020> name: (null) disposing (null) after bound value 4
2012-11-25 16:42:15.528 otest-x86_64[68214:707] <RACSignal: 0x7fafb3a03020> name: (null) completed
2012-11-25 16:42:15.528 otest-x86_64[68214:707] ReactiveCocoa/ReactiveCocoaFramework/ReactiveCocoaTests/RACSignalSpec.m:87 expected: (0, 1, 2), got: (0, 1, 2, 0, 2)
ReactiveCocoa/ReactiveCocoaFramework/ReactiveCocoaTests/RACSignalSpec.m:87: error: -[RACSignalSpec _RACStream__taking_with_a_predicate_should_take_until_a_predicate_is_true] : expected: (0, 1, 2), got: (0, 1, 2, 0, 2)
Test Case '-[RACSignalSpec _RACStream__taking_with_a_predicate_should_take_until_a_predicate_is_true]' failed (0.005 seconds).

The failures here look like another manifestation of #94, but for a finite signal (somehow).

@Coneko
Copy link
Member

Coneko commented Nov 26, 2012

Yep, it's definitely #94.
The signal in the test is created by calling the primitives +empty, +return: and -concat:. The first two primitives don't give the subscription a chance to dispose itself before sending nexts and completed, the latter doesn't exhibit the behavior per se, but propagates it.

@jspahrsummers
Copy link
Member Author

@Coneko Thanks for the pointer.

I've added a workaround so that -bind: doesn't send more values than it should, but it doesn't address actual termination of the subscription.

@jspahrsummers
Copy link
Member Author

This should be ready for review and merging now (contingent upon #134).

There are probably still a few other methods that could go into <RACStream>, but this is sufficiently disruptive for now. :trollface:

The resulting combined logic should be easier to follow and fix.
@jspahrsummers jspahrsummers reopened this Nov 27, 2012
// as determined by `==` or `isEqual:`.
//
// Returns a stream of the receiver's values with sequential repeats removed.
- (instancetype)skipRepeats;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this actually useful?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just distinctUntilChanged generalized. I don't see why we'd want to keep it confined to <RACSignal>.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I'm just not sure it's actually useful for sequences. A method to get a distinct sequence, sure, but this seems minimally useful.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to be a pretty common question for NSArray, at least.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, so a method that removes all duplicates would be useful but this "Returns a stream of the receiver's values with sequential repeats removed."

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, quite right. I misinterpreted that search.

I'll revert this change.

// Returns a stream which sends a RACTuple for each value in the receiver, where
// the first object in the tuple is the value from the receiver, and the second
// object in the tuple is `weakObject`.
- (instancetype)injectObjectWeakly:(__weak id)weakObject;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd actually been meaning to remove this method entirely. Any objections to doing that instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why's that?

I know we don't use it, but I could see the strong/weak dance being abhorrent to some people.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it leads to more awkward code than the strong/weak dance does.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@joshaber
Copy link
Member

Other than the 1 comment about removing -injectObjectWeakly:, this looks ✨ to me.

@ghost ghost assigned joshaber Nov 28, 2012
@jspahrsummers
Copy link
Member Author

📦

@joshaber
Copy link
Member

🍢

joshaber added a commit that referenced this pull request Nov 28, 2012
Move more methods into <RACStream>
@joshaber joshaber merged commit 13b1fa0 into master Nov 28, 2012
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

Successfully merging this pull request may close these issues.

None yet

3 participants