<RACStream> monad, RACSequence

[jspahrsummers]

#89

Added a lazy RACSequence class, and abstracted common APIs between it and <RACSubscribable> into a new <RACStream> protocol. I'm definitely open to better names for these guys.

RAC should be tagged before this gets merged in.

[Coneko]

I don't like methods being declared as properties when they're not KVO compliant, but I understand nonatomic and copy make for good hints on what considerations must be made when calling them and cocoa collection classes can't be observed anyway, so I can't really say declaring them as plain methods would be better in these cases.

[Coneko]

-flatten would probably be better called -join, and could be implemented as

- (id<RACStream>)join {
  return [self bind:^id<RACStream>(id value) {
    return value;
  }];
}

so it doesn't have to be a required method.

[joshaber]

BTW, I fully expect some do syntax using crazy macros

[joshaber]

Why would this need to be on RACSequence instead of RACStream?

[Coneko]

He did mention he still had to move some methods from RACSequence and RACSubscribable to RACStream.

[jspahrsummers]

Yeah, @Coneko nailed it. This was added before the protocol (just to demonstrate to myself that the primitives I had were good enough). It's going to go into <RACStream> later.

[joshaber]

Overall I ❤️ ❤️ ❤️ the direction this is going 👍

[dannygreg]

Pretty sure you mean RACSequence here.

[jspahrsummers]

derp

[jspahrsummers]

@Coneko Good call on the default implementation of -flatten.

Although join is a more correct name, I'm hesitant to use terminology which is going to be extremely unfamiliar to Cocoa programmers, especially when clearer alternatives exist.

[jspahrsummers]

I still can't think of a solution to the take: problem without giving the flattenMap: block another parameter. Haskell doesn't really suffer from this problem because everything is lazy by default.

[Coneko]

Why not take the easy way out and have RACSubscribable have a custom implementation of take: instead of inheriting the one from <RACStream>?

[joshaber]

Yeah, though I bet -take: won't be the only case with this problem.

[jspahrsummers]

It's worth noting that sequences have a similar, though less severe, problem. take:1 shouldn't result in the original sequence trying to resolve two values.

It'd be nice to have a generic solution for <RACStream>.

[Coneko]

You should change stream to be id instead of id<RACStream> since all other cases where a stream of the same type was required have been typed with just id.

[jspahrsummers]

Those cases (return types of blocks) have been because of Objective-C's limited type system. When we can type things as id<RACStream> without issue, we should.

[Coneko]

It mimics the "terminating subscriptions immediately" issue in #94 doesn't it? In both cases the existing interface is elegant, but doesn't cover some very particular edge cases, and having to dirty the interface to cover them is frustrating.

On an unrelated note, how come sequences only have a class cluster, and not a concrete protocol too like subscribables?

[jspahrsummers]

On an unrelated note, how come sequences only have a class cluster, and not a concrete protocol too like subscribables?

I think if you have a type that you want to be sequencable, it's trivial to write an adapter, just like what's done for the built-in collection classes right now.

Honestly, I would rather subscribables not be a protocol, but there are some legitimate use cases for it that I don't find as applicable to sequences. See #35 for some more discussion.

[jspahrsummers]

Added -[RACSequence subscribableWithScheduler:] and <RACSubscribable>.sequence to convert between the two. Also fixed the issue with take: (for both kinds of stream) by adding a BOOL *stop parameter to the block of flattenMap:.

[Coneko]

I'd say -flattenMap: doesn't need to accept a return value of nil anymore, one can return empty if she/he wants to stop without adding a value.
Users might otherwise think when you return nil setting the stop flag doesn't make any difference.

[jspahrsummers]

There is a semantic difference between returning nil and returning empty, though. My hope is that binds won't generally need to be terminated by users anyways – the stop parameter is more for implementing other <RACStream> methods.

[joshaber]

Alright so the one last thing. We talked about this in person, but I think it's better to go back to -bind: being the primitive and then provide a -flattenMap: without the stop parameter.

[jspahrsummers]

💥

[joshaber]

✊ 👊 ✌️