fruity
fruity copied to clipboard
I'd like to contribute
Hi @nvzqz!
I'd like to contribute to this library in at least the coming 6 months. My motivation would be to create a safe(er) replacement for objc
and related crates (I tried improving that first, see https://github.com/SSheldon/rust-objc/issues/101) that I can use in winit
and personal projects.
But before I start throwing code at you I'd like to get an estimated answer to the following questions, just to get a feel for the state of the library (and you :wink:):
- Do you want to receive and review PRs?
- How do you feel about the project right now? Burnt out or do you still believe in it?
- What are your long-term plans for this library?
- Would you be open to putting it in a GitHub organization at some point (or asked another way, how much "ownership" of the library do you feel?)
Also, would you be open to supporting declaring custom classes? This is required in many cases for implementing delegates. If yes, there's at least three parts to it:
- The declaration part itself. See
objc::declare
for an example implementation. - Letting users choose which traits are implemented for their own custom classes; this would require some form of subclassing, maybe the design that
objc-foundation
uses (having traitINSString
and concrete implementorsNSString
andNSMutableString
), or something else entirely. - Message-sending macros would have to be public API
Concrete improvements I would like to make is:
- Rework
Arc
to have a notion of ownership, so that we can have safe mutability (a lot like inobjc_id
) - Add a
AutoreleasePool
type to let you return references to autoreleased items. See https://github.com/SSheldon/rust-objc/pull/103 for more info. Would allow a safeNSString::to_str
. - Add helper types to indicate operations that are only safe on the main thread and/or after the NSApplication has been initialized
- Maybe implement some of the generic types in Foundation
- Bringing the
exception
andverify_message
features ofobjc
to this crate as well - Improve testing of
NSString
(especially the hacky macro) - Start adding some AppKit classes, at least for the things I need :wink:
Hope you have a nice day!
@madsmtm 🙌 @nvzqz 👋😃
I started work in a private fork (of objc
), will update you @mikeumus when I've got something to show for
Hey, I've released my fork of objc
now: objc2
.
It hasn't change much from objc
in the API surface, and is missing a lot of things that fruity
has, namely:
- Static
NSString
s (probably won't come for a while because of issues with it's stability, and it probably also has to be adapted to work on GNUStep), tracked in https://github.com/madsmtm/objc2/issues/53 - Ergonomic Foundation types, tracked in https://github.com/madsmtm/objc2/issues/58
- Reference-counting type that can work generically with Core Foundation, Objective-C and libdispatch types (Probably won't happen, we have
objc2::rc::Id
which works with Objective-C types, and then one should create new types for the others).
And fruity
also has a lot of libraries, which is out of scope for objc2
, e.g.:
- Core Foundation types
- Core Graphics types
- libdispatch
- ...
But still, you may find it useful ;)