Copyright 2004 by M. Uli Kusterer Fri, 29 Nov -1901 11:06:32 GMT Comments on article blog-plugins-with-cocoa at Zathras.de http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) en-us http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment8 http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment8 Uli Kusterer writes:
Clark, the iPhone uses the new runtime. Too bad that the iPhome simulator still uses the old one.
http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment7 http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment7 Uli, the macro __OBJC2__ is never defined on the old runtime. It is the correct macro for detecting whether or not code is being built for the new (i.e. 64-bit/iPhone) runtime.

Harvey, no, the iPhone uses the new runtime, and does not suffer from the fragile base class problem.
http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment6 http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment6 Uli Kusterer writes:
Yes, even if you don't export the symbol, they still end up in the table that NSStringFromClass and NIB loading use.
http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment5 http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment5 Torsten Curdt writes:
So in other words really every private class should be prefixed? Darn - thought only the ones that get exported.
http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment4 http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment4 Clark, 64 bit definitely does not have the fragile base class problem. I believe the iPhone does still have this problem though. Can you provide a link to documentation that says otherwise?


For avoiding class name collisions, this is important but super long class names are hard to read. Using a #define can work around most of this.

#define RBSplitView UKHulaHoopPluginRBSplitView

(You still need the @interface to use the true class name or IB will be confused.)


"not to let your plugins subclass classes in the host application"
This is definitely an all-around better idea. Do this if you can afford it at all. It's much less work to support.
http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment3 http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment3 Uli Kusterer writes:
Clark, thanks, I've amended the article with the general info. The __OBJC2__ constant isn't a good choice, though, as you can have that on the 32-bit runtime as well, I think (for @property and @synthesize etc.).
http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment2 http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment2 Karsten writes:
I just wanted to point to a bundle that i wrote that can load plugins into an application. It automatically searches the user's folder, in the system's folder and in the application's folder.
It's under MIT license and available on codebeach:
http://www.codebeach.org/code/show/5

Karsten
http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment1 http://www.zathras.de/angelweb/blog-plugins-with-cocoa.htm#comment1 Note that under the "new" runtime (i.e. iPhone and 64-bit), there is no fragile base-class problem, so the padding is unneeded there. If you do use extra variables for padding, wrap them in:

#ifndef __OBJC2__
...
#endif

to make sure that they are only defined on the legacy runtime.