-
Notifications
You must be signed in to change notification settings - Fork 44
Combine Consistency
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:
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.
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 ofSubscription
is "TryMap", but forPublishers.Map
it's "PassthroughSubject".
Mirror is not part of our public API, obviously.
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
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.