Hey @yury, we talked a bit about about this over email, but I wanted to elaborate in full.
I think it would be beneficial for our two projects to collaborate, since we're both defining API(s) over Apple's frameworks - especially our abstractions over the Objective-C runtime would benefit from collaboration.
Concretely, I think a shared codebase for this is the way to go.
I believe the best way forward here would be for cidre
to build upon objc2
, since objc2
was built with the idea of it being a library that others can use like this - but if you think it would make more sense to make some kind of objc-core
crate, I would be fine with that as well. In general, just sharing ideas and discussing things should also provide a great benefit to both of us, so please treat this proposal of cidre
moving to objc2
as just that; a proposal ;).
Looking at your stated goals, I think the bits about performance is fully compatible with mine, I very much want to make it possible to have fast, zero-cost interaction with Objective-C! Your other goals, i.e. Rusty API / ML friendly, can still be pursued by this crate while using objc2
.
Although objc2
tries to support older platforms, your explicit goal of not doing so is not incompatible with it; I would be completely on-board with adding a feature flag to enable newer features that would yield higher performance (in fact, I am working on functionality to do this based on the deployment target, so the user wouldn't even have to do anything).
With that out of the way, let me try to outline the pros and cons of cidre
moving to objc2
:
Pros
- Vastly improved safety/soundness. See #3 for a few of the cases that would be fixed by using
objc2
.
- Interoperability with the rest of the ecosystem (provided people decide on
objc2
being "the ecosystem", of course).
- A shared place to add performance improvements (so if I find something that can be improved,
cidre
would benefit as well).
- Less code for you to maintain.
- More eyes on and real-world usage of the shared code.
Cons
-
Since Allocated<T>
is a struct in a different crate, you can't implement init
methods for this the same way you're currently doing it. Specifically, you would either have to provide new
methods that does the allocation internally, or live with having to do Data::init_with_bytes(Data::alloc(), bytes)
in the interrim.
Note that arbitary self types are somewhat nearing stabilization, which would solve this issue completely.
-
objc2::rc::Id
(the equivalent to cidre::arc::Retained
) does not allow overriding the retain
/release
implementations, so CoreFoundation may be a bit harder for you to support.
I am still not sure of the best approach here, so very willing to discuss this part!
-
The code lives somewhere that you don't control, which will make it harder for you to make changes.
What do I gain?
I'm trying to win you over to using objc2
because I believe your input, as well as performance improvements you find, would be valuable to the project.
After all, the more use-cases objc2
can satisfy, the more users it has, and the better off the project is!
Implicit in the above is that I'd be willing to shape objc2
to fit your goals, if needed!
I hope you don't take offense to this proposal, again, if you disagree with this, I would still like to collaborate!
Feel free to contact me on email or on Element (@madsmtm:matrix.org
) if you want to discuss things in a private medium/more synchronously.