You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 20, 2018. It is now read-only.
In @ReactiveCocoa, we've basically followed a scorched earth policy with regard to Rx compatibility, on the following basis:
Most users (and especially potential users) of RAC do not have experience with Rx, so any commonalities are lost upon them
LINQ terminology is often less intuitive than ML-inspired naming for our users (which may be surprising given Objective-C's Smalltalk ancestry)
We care a lot about doing things The Right Way™, and correcting perceived mistakes in previous versions of RAC or Rx, even at the expense of backwards compatibility
We incorporate a lot of ideas from @paulcbetts' ReactiveUI, which we're able to integrate holistically due to our complete control of the implementation
Objective-C is a highly dynamic language, so we can emphasize patterns that are simply not possible in other languages — e.g., the ability to observe arbitrary method invocations lessens the need for subjects
I mention all of this because others have emphasized consistency (across implementations) to a degree that we haven't really been interested in. It might be worth talking about this in more detail at a summit, and deciding whether our approach is good or needs adjustment.
I don't think it's super important in the case of RAC because it really is on its own. RxJS for example treads on locations that Rx.NET cannot handle as well. I imagine the same would apply to Ruby, Python, etc. As long as we have a core understanding of some of the fundamentals and The Right Way such as:
Core objects of Observable/Observer
Enforced grammar of OnNext (0-N) | (OnError | OnCompleted)
Composition Operators
Notion of Schedulers to allow for changing of concurrency model at any point.
@paulcbetts Though it wasn't my intention, I don't think there's anything wrong with having these discussions asynchronously. Frees up more in-person time, and makes the results highly visible.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In @ReactiveCocoa, we've basically followed a scorched earth policy with regard to Rx compatibility, on the following basis:
I mention all of this because others have emphasized consistency (across implementations) to a degree that we haven't really been interested in. It might be worth talking about this in more detail at a summit, and deciding whether our approach is good or needs adjustment.
@joshaber
The text was updated successfully, but these errors were encountered: