As has been pointed out several times, it's a really bad idea to have
the same-named class in multiple plugins. The Objective-C runtime will
load the first class instance it finds (in your case, in the first-
loaded plugin). For all other plugins, when the class is referenced,
that first class instance is used, so calling [NSBundle bundleForClass:
[self class]] will cause it to return the bundle for that first
plugin, no matter which plugin is asking. This answers your question
about code knowing its containing bundle. You made an assumption about
where the plug-in's code was loaded that turned out to be incorrect.
If you want to use the same class code for each plug-in, I would
suggest that you use a #define to rename the plug-in class at build
time, and add a per-target definition containing a unique class name.
Then your common class would be renamed automatically for each target.
If you have to specify the plugin class in, say, your Info.plist, you
could use the same build definition.
@interface PLUGIN_CLASS_NAME
...
@end
@implementation PLUGIN_CLASS_NAME
...
@end
The benefit of going with this model is that you still maintain a
single code base for all of your plugins, even though the class is
renamed on a per-plugin basis; you eliminate the "which plugin am I"
problem you're running into now; and you don't have to worry about
having an older plugin version that happens to load before a newer
version, thus forcing all the newer plug-ins to use the older plug-in
code.
On Nov 15, 2009, at 3:36 AM, Motti Shneor wrote:
Thanks, but the bundleWithIdentifier has its own problems.
1. The identifier is (as far as i know) accessible only from the
bundle itself, which I don't have! I'm circling around here, without
access to my own resources! Must I hard-code the bundle identifier
as a string constant within each of my plug-ins?
2. Even if I DO follow this rule, how can I manage to distinguish
between two bundles that include the same plug-in but from different
versions?
They have the same class, and the same identifier!!!!
Really, Isn't there a way for a library (dll, dylib framework etc)
to know what is its containing bundle?
On 10/11/2009, at 19:42, Douglas Davidson wrote:
On Nov 10, 2009, at 4:59 AM, Motti Shneor wrote:
Thanks guys, but you may have not read all my message ---
The [NSBundle bundleForClass:[self class]];
is unusable for me, because I have many plugins that build from the
same code, and export the same class (of course --- the same class
name).
Obj-C has no name-spaces, and so, If you load 2 such plugins, and
use the [NSBundle bundleForClass:[self class]] in each of them
independently --- you'll get erroneous answers! both of them will
return the same bundle although they come from different bundles.
This is hardly a system "bug" because there are no namespaces, and
for the same class name there is only one bundle.
As others have said, don't do this. However, to answer your
question,
the other way to locate your bundle is via bundleWithIdentifier:.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
