Skip to content
This repository was archived by the owner on May 10, 2025. It is now read-only.

Combine Consistency

ddddxxx edited this page Oct 17, 2019 · 22 revisions

CombineX is committed to providing identical behavior with Apple's Combine. Any inconsistent behavior is considered as a bug. Our test suit also run against Apple's Combine.

However, there's still some behavior that not guaranteed to be consistent with Apple's Combine:

Extensions on Standard Library, Foundation, and Dispatch

It's not possible for technical reason. Currently Swift is not able to disambiguate between two modules that define the same method or property. Directly extending these type introduces ambiguity therefore you can use neither of them. This bug is tracked here.

To solve this problem, we introduced cx namespace. You need to write result.cx.publisher or dispatchQueue.cx.schedule(...). We promise their behavior is consistent beside cx namespace.

Description and Mirror

Protocol conformance consistency is our goal. But we decide to treat CustomStringConvertible and CustomDebugStringConvertible as implementation details. Our objects still conforms to these protocol, yet they might returns different description and debugDescription than Apple's Combine. Here is the reason:

  • They are mostly used in debugging situation.
  • It adds a lot of bikeshedding work without obvious benifit.
  • The behavior of Apple's Combine is not consistent and actually leak implementation details. e.g: for Publishers.TryMap, Description of Subscription is "TryMap", but for Publishers.Map it's "PassthroughSubject".

Mirror is not part of our public API, obviously.

Utility Module

If you use CombineX as dependency, you may find following modules are also importable. It's not public API, use on your own risk.

  • CXUtility

Others

If you find any other inconsistency, please file a bug. Or even better, create a pull request that either fix it, or add test case about it.

Clone this wiki locally