Advice for Cocoa Plug-ins & Objective-C implementation uniquing
Advice for Cocoa Plug-ins & Objective-C implementation uniquing
- Subject: Advice for Cocoa Plug-ins & Objective-C implementation uniquing
- From: Jonah Petri <email@hidden>
- Date: Mon, 1 Feb 2010 13:13:20 -0500
Hello,
We're working on getting our plugins converted to Cocoa, and I've come across a seemingly difficult issue.
We ship multiple plugins based on common backend framework code. Up to now, we've linked our entire stack into each plugin bundle. Then, if the user loads 4 of our plugins into a host app, they end up with 4 (possibly different!) copies of our common code. This keeps the implementations of our plugins completely separate, and keeps our testing matrix simple.
Now, in order to make the cocoa & 64-bit transition, we have to introduce some objective-C into our code. Then dyld gets involved, and (presumably as part of the objective-C contract?) uniques the implementations of any identically named classes at runtime. This is seen from messages such as:
objc[70421]: Class IZSupportClass is implemented in both [plugin 1] and [plugin 2]. One of the two will be used. Which one is undefined.
This means trouble for us, as we can't be sure that the code that we wrote will actually be what's run!
How do other folks deal with this?
One way is to use a shared library (or framework) for common code. Apple has ProKit.framework, which supports their pro-apps. Then, you take on the extra burden of ensuring backwards compatibility of your library with old versions of your plugins. This seems onerous for us.
Another possibility is to create unique names of our classes for each build. This seems to most closely emulate the solution we had before, and is appealing for that reason.
Alternatively, if there were a way to ask dyld nicely for a specific implementation of a given class, that would also work. I've not experimented with this yet, but it seems fraught with peril.
Thanks for any advice!
-Jonah _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden