Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Praise! (Also, let's collaborate!) #1

Open
madsmtm opened this issue Dec 23, 2021 · 0 comments
Open

Praise! (Also, let's collaborate!) #1

madsmtm opened this issue Dec 23, 2021 · 0 comments

Comments

@madsmtm
Copy link

madsmtm commented Dec 23, 2021

Goodness, can't believe I haven't seen this crate before now!
I mean, there's so much good stuff in here, I've looked at it for like an hour and only really scraped the surface; I'm amazed!

... Phewh, getting down from this high, let's talk business! We clearly both have our gripes with the widely used objc, so how about we try to establish some common ground, and work together to take over the world help the ecosystem forward? (Just for reference, in case you didn't know, my work is over here).

The past

I think we've taken two different approaches to this problem; I forked the original objc, while you've been free from the shackles and developed something completely new; this means there's obvious differences (especially in naming), but actually in a lot of areas I see we've converged on similar solutions.

As exemplified by our brief discussion in gfx-rs/metal-rs#222: Sure, we may not fully agree yet on exact details (honestly I'm very unsure what I think is the best design here), but here we both invented the same basic fn autoreleasepool that gives a "managed" &AutoreleasePool to its closure.

What I'm trying to say that this is a good thing, a really good thing! If we've both independently thought hard about the problem, and still arrived at (approximately) the same solution, there must be some merit to that solution!

The future

In the end, though, this is a niche area, and there can't be two crates on the throne; if we want to get rid of the de-facto objc (hint: we do), we shall have to combine efforts to slay the mighty beast (read: provide and spread a better alternative).

Just to prevent any miscommunications, here's my ideal future, what I would like; that does not mean it can't change, but I feel it's important to state very explicitly, since we both have some sort of stake in this game, and having hidden motives will not help us forward:

  • I believe that objc2 it is the right approach if widespread ecosystem adoption is desired. Given the nature of it being a fork, it has inherited the stability and familiarity of objc - both important factors when proposing to others to switch to your crate!
  • Given that, I would like to integrate the improvements and developments in this crate into objc2 as we see fit.
  • Notice I used "we" in the above sentence? I would like have you on board on this journey, that would include making you a co-maintainer in my repository (which doesn't have to be mine in the future either, we could move it to a GH organization like @rust-windowing).

Note that I have spent a lot of time on objc2 (a bit too much on polish, a bit too little on solving real problems), and I probably have some attachment to it by now, which I recognize may influence my decision-making, so stating explicitly again: My opinions are not set in stone, they can change if need be.

Outtro

Anyhow, let me know what you think of this. I know, I know, it's a blunt move just barging in saying "go over and work on my project", if you wanna do something else that's entirely fine, this is truly only meant as a discussion starter!

If you want, we can get in touch over Discord (madsmtm#2338) or Matrix (@madsmtm:matrix.org) (if you're indifferent then I'd prefer Matrix), it's usually easier to talk about these kinds of things on a looser medium.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant