Re: Advice for Cocoa Plug-ins & Objective-C implementation uniquing
Re: Advice for Cocoa Plug-ins & Objective-C implementation uniquing
- Subject: Re: Advice for Cocoa Plug-ins & Objective-C implementation uniquing
- From: Vojtěch Meluzín <email@hidden>
- Date: Mon, 1 Feb 2010 19:28:47 +0100
How about telling Apple and customers, that we are not going to do that... ;) I mean, we are following Apple's riddiculous errors all the time... Forcing us to use the crappy objective-C is far beyond the limits, and using prefixes on the code :))))... Well, this is way beyond amateurism...
2010/2/1 Olivier Tristan
<email@hidden>
On 01/02/2010 19:13, Jonah Petri wrote:
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.
Most people use prefix on their cocoa code to avoid conflicts as far as I know.
--
Olivier Tristan
Ultimate Sound Bank
_______________________________________________
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
_______________________________________________
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