Plans for collaboration with objc2?

[madsmtm]

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 Soundess issues #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.

[yury]

I didn't reply bc I'm thinking how we could collaborate and how can I use objc2.
Don't have solution yet - just sharing what in my head.

1. Using unchanged Objc naming in rust code feels really alien to me. Like I'm writing smth wrong in rust. That is why I do naming translation. Also I try to provide hints to users what to expect (_ar, _throws). I know that it is more just notation, but still very useful. Also, I found modules more convenient instead of prefixes (a lot). I try make, that cidre is really rust lib.
2. When I do porting (I can do it in work breaks, at night, in the bus...) I took small portion of Apple framework and I learn it. Experimenting etc. I don't wanna miss that part too. Generators/translators are good, but understanding is important for me too.
3. Cidre also have many C frameworks ported. They have quirks too.
4. Apple is trying to adopt frameworks API to be more swifty. Objc2 don't make API to be more rusty (length vs len etc...). It is just translates it correctly (no claims here. This is valid and correct approach too.).

This is first part, just sharing...

[madsmtm]

Yeah, I recognize all of these, which is why I wrote objc2 instead of icrate.

While the latter may be useful to you internally, to verify that the types you've written are correct, and while it has the possibilty of doing some of the things you've named here in the future (name translation, C framework support, more Rusty), this proposal was mostly about using just objc2, which is a nice Rusty API.

Thanks for your thoughts, they are good points for how I could improve icrate in the future such that you would want to contribute to / use that!

[yury]

Closing this issue. Feel free to reopen if needed.