Merging efforts about combinex

[ddddxxx]

The difference between CombineX and OpenCombine, FYI.

Diff	CombineX	OpenCombine
First Commit	Jun 9, 2019	Jun 10, 2019
Progress	Almost 100%	About 30%
Managed by	Organization	Individual
Combine Compatibility	Yes (with CXCompatible and CXShim)	No
Side Projects	CXCocoa and CXExtensions	No
Dependency	Foundation.NSLock	No
Supported Platform	Apple, Linux, Windows	Apple, Linux
Supported Library	Foundation and Dispatch (with CXFoundation)	Dispatch (with OpenCombineDispatch)
API / Behaviour Consistency	Yes	Yes
Description / Reflaction Consistency	No	Yes

[ddddxxx]

Corresponding issue: OpenCombine/OpenCombine#80

[AlexisQapa]

Thanks

[broadwaylamb]

If we're doing comparison here, I guess it'd be fair to add that:

• OpenCombine does not depend on Foundation and Dispatch (except for OpenCombineDispatch and OpenCombineFoundation shims that were deliberately moved into separate modules). CombineX uses Foundation's NSLock under the hood for locking, AFAICT.
• Just checked: out of 348 tests in the OpenCombine test suite, 162 are failing when run against CombineX and passing when run against Apple's Combine. 1 test results in a crash (so I commented it out). This is 46% fail rate. And those are the tests that compile. There are actually more tests in the OpenCombine test suite, but they don't compile because some publishers in CombineX don't conform to Equatable, when they should.
• Out of those 115 CombineX tests that compile against OpenCombine (yep, in OpenCombine fewer operators are implemented, for now), only 15 are failing when run against OpenCombine, resulting in 12% fail rate.

Yep, I could quickly implement the remaining operators with the semantics "somewhat close" to Combine and after that start gradually fixing it, but I chose to polish all the nontrivial corner cases before releasing the code with unexpected behavior, so that it has exactly the same semantics (and performance!) as Combine. Both approaches are perfectly valid, but I personally most enjoy the latter.

But still, great job with implementing the functionality so quickly, @luoxiu!

(Attaching the files so you could reproduce my test results)

• OpenCombineTestsAgainstCombineX.zip
• CombineXTestsAgainstOpenCombine.zip

[FranzBusch]

I also think merging efforts makes sense and there should be a way to find a common way of doing implementation and git workflow etc. I think both sides have their advantages and disadvantages. it feels like a wasted effort with two projects aiming to do the same thing. Maybe we can start with a common test suite.

[luoxiu]

@broadwaylamb Wow! Thanks!

I will trace these failed tests~ As I said on README, at the moment, the number of tests is far from enough, we do need more tests.

[luoxiu]

@broadwaylamb I just deleted a reply because my partner @ddddxxx said it was a bit offensive to read.

If it's true, sorry for my poor English, 🤣

[broadwaylamb]

@luoxiu no worries, I haven't found it offensive at all.

[luoxiu]

@FranzBusch

Thanks for the advice! I am willing to learn OpenCombine's advantages. As for merging, that would be very troublesome...

[ddddxxx]

@broadwaylamb Thanks for your clarification (I've updated my comparison between CombineX and OpenCombine). I think we all agree that due to different design choice we made, Merging CombineX and OpenCombine do more harm than good. Though there's still some waste efforts can be avoided. I think we could share test cases.

CXShim is designed to filling the gap between different Combine implementation. We can build tests on it.