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: Jean-Daniel Dupas <email@hidden>
- Date: Mon, 1 Feb 2010 20:01:23 +0100
Le 1 févr. 2010 à 19:13, Jonah Petri a écrit :
> 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.
>
This is not a dyld limitation, but an objc runtime one. As the runtime cannot handle 2 classes with the same name, you cannot ask for a specific implementation.
-- Jean-Daniel
_______________________________________________
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