Remove NSObject+RACFastEnumeration

[jspahrsummers]

The rac_toSubscribable method is pretty similar to the rac_sequence functionality provided on the built-in collection classes. Arguably, the laziness of rac_sequence also leads to a better API.

[Coneko]

Is there going to be a method to get a subscribable from a sequence?
I'm using rac_toSubscribable to work with arrays of subscribables by converting them to subscribables of subscribables and then back to arrays.

[jspahrsummers]

There's not really a sane way to do that, given that sequences are meant to be used lazily. I would recommend instead setting up APIs to use <RACStream> and not care about the specific stream type.

[joshaber]

Though you can't really use subscribables and sequences interchangeably since the accessing is different.

[jspahrsummers]

@Coneko Is there any reason not to use a sequence of subscribables for the case you describe?

[Coneko]

I can't -flattenMap: a sequence of subscribables, but I guess I could always use -map: on the sequence and then call +merge: with the resulting array.
Although +merge: itself is implemented through -rac_toSubscribable and -flatten.
Is that going to go too? I use that quite a bit as well.

[jspahrsummers]

Maybe the right answer here is to move -first, -array, etc. into <RACStream> proper, so that values can be retrieved from streams in a generic way.

[Coneko]

It doesn't really relate to those in my case.

I use +merge: when I want to subscribe with the same subscriber to multiple subscribables. For example several NSNotificationCenter notifications, where the selective logic is dependent on the properties of the notification rather than the source of it.

I use -rac_toSubscribable followed by -flatten when I have arrays of asynchronous tasks, or of objects on which I have to execute asynchronous tasks. The interface for those are subscribables that send a next with the result of the computation, or just error or completed if the task is a side effect.
So basically it goes array of objects -> -rac_toSubscribable -> subscribable of objects -> -map:, -filter:, etc -> subscribable of tasks -> -flatten, -catch:, etc -> subscribable of results -> -toArray, -finally:, -subscribeCompleted:, etc -> array of results. I actually don't use toArray because it deadlocks in most of those cases, but I use something equivalent.
I find it pretty handy, but I guess it doesn't really fit in the subscribables are a push-based stream of values view.

[jspahrsummers]

I'll add sequence <-> subscribable conversion methods to #92, I think, and then still remove rac_toSubscribable from NSObject. That seems to be the best way forward, since it discourages turning arrays into subscribables, but still provides a way to do it.

[Coneko]

Works for me. I'll probably start using sequences in many places where I'm using arrays now once that one goes through anyway.

[thenikso]

Why converting an array to a subscribable instead of a sequence should be discouraged?

Aren't those to be seen as two different instances of the RACStream monad that you can pick an choose depending on your needs?

As @Coneko is saying, building subscribables starting form an array is a pretty common task in here.

[jspahrsummers]

@thenikso Sequences form a better abstraction for arbitrary computation, while subscribables are better for asynchronous or reactive streams of values.

It's not that arrays shouldn't be used as subscribables — simply that sequences make more sense for most such cases, and so should be the default.