You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Id struct was moved into an external crate in 81a972f, but it seems fundamental enough to exist in this crate in some form.
It was removed because, although its design satisfied the requirements of my foundation wrapper, it isn't compatible with the cocoa crate. The cocoa crate is a lower-level wrapper that operates with raw pointers, so it expects objects as *mut Object where the Id struct could be dereferenced to &Object.
The smart pointer should return with a design that will also be usable by cocoa and other libraries without requiring that users put a lot of effort into determining a safe interface for them.
The text was updated successfully, but these errors were encountered:
I think the best bet here is to expose a lower-level representation in objc that higher-level representations can be built atop. That way cocoa can keep working directly with object pointers while objc_id can offer a fully safe interface.
The cocoa crate doesn't handle reference counting, so I think there would be merit in considering moving the objc_id functionality back into this crate - but I've opened #101 for that.
The
Id
struct was moved into an external crate in 81a972f, but it seems fundamental enough to exist in this crate in some form.It was removed because, although its design satisfied the requirements of my foundation wrapper, it isn't compatible with the cocoa crate. The cocoa crate is a lower-level wrapper that operates with raw pointers, so it expects objects as
*mut Object
where theId
struct could be dereferenced to&Object
.The smart pointer should return with a design that will also be usable by cocoa and other libraries without requiring that users put a lot of effort into determining a safe interface for them.
The text was updated successfully, but these errors were encountered: