Cloning Destination/Source? about coremidi

[Boddlnagg]

I was finally able to work on this again, and it turns out that Arc<Destination> works just fine 👍

[chris-zen]

@Boddlnagg that integer is an opaque handler to a CoreMIDI resource, if we clone it, then, there would be two owners for the same object, which violates the rules from the borrow checker.

Could you use an Arc<Destination> ?

I think I am doing something similar here:

• https://github.com/chris-zen/hero-studio/blob/master/app-native/src/midi/coremidi.rs#L81
• https://github.com/chris-zen/hero-studio/blob/master/app-native/src/midi/coremidi.rs#L117

The alternative would be to use certain features from the CoreMIDI API to retrieve the object unique id, and use it to create a new Destination instance (but this is not fully supported by the rust coremidi lib yet, although you could add the exports yourself).

[Boddlnagg]

Yes, looking at the definition of Destination, cloning would need to clone all the way down to the underlying Object. And I thought it might be possible, because there's no Drop implementation. So technically the ownership semantics is not encoded in the type (this is somewhat related to #8), but I do understand that this would be a little un-Rust-y. So it's totally okay if you don't want to go that route.

However, thank you for the hint towards Arc<Destination>, I think that should actually work, and if it doesn't, I will use MIDIObjectFindByUniqueID (I can add the export myself, but it would still be nice if you could add something like Destination::from_unique_id, although I don't know whether that would need to be unsafe because you don't know from a unique ID if it actually refers to the right kind of object, right?).

[chris-zen]

Please try Arc<Destination> and if it doesn't work for you, we can talk about Destination::from_unique_id. This was in my mind before, but not as a priority thing.
About the unique id not existing anymore I guess this shouldn't be a problem as the factory method could return a Result.