Description
Blocked on at least #21.
Fundamentally cannot be made safe, since you're calling into unknown Objective-C classes. Not even sure add_ivar
is sound (since Objective-C could be using the same ivar in a superclass)?
-
Fix Adding a method isn't ergonomic SSheldon/rust-objc#12
Fixed by Consistently implementMethodImplementation
wrt. lifetimes #193. -
Rename
ClassDecl
->ClassBuilder
-
Can it be made more ergonomic with macros? See More macros SSheldon/rust-objc#74.
Done in various PRs (primarilydeclare_class!
macro) -
Returning an autoreleased object in a custom / overridden method is very unergonomic:
extern "C" valid_attributes(_this: &Object, _sel: Sel) -> *mut NSArray { let array = Id<NSArray, Owned>::from(vec![...]); array.autorelease(pool) // Uhh, we don't have a pool from anywhere; it is implicit in Objective-C } let mut decl = ClassDecl::new("MyView", class!(NSView)).unwrap(); decl.add_method( sel!(validAttributesForMarkedText), valid_attributes as extern "C" fn(&Object, Sel) -> *mut NSArray, );
Will also need something like an
autorelease_return
method onId
which callsobjc_autoreleaseReturnValue
.Fixed by Add
Id::autorelease_return
#191. See Addautoreleasepool_leaking
#112 as well for an alternate solution. -
Differentiate between static class references and "registered" classes, see Sending messages is inefficient because of selector lookup SSheldon/rust-objc#49 (comment)Moved to Add static classes #185. -
Memory management rules are not automatically followed. Fixed by Allow returning
Id
fromextern_methods!
#244 -
Uninitialized data in
init
methods. Fixed by Better ivar initialization #252 -
Allow
Drop
types in ivars. Fixed by AllowDrop
types in ivars #254