Re: Strategies to prevent class name clashes
Re: Strategies to prevent class name clashes
- Subject: Re: Strategies to prevent class name clashes
- From: Uli Kusterer <email@hidden>
- Date: Fri, 15 Feb 2008 11:43:51 +0100
Arne Scheffler wrote:
I already got a problem while porting that two plug-ins that uses
the toolkit were compiled at different times with different code.
But as a nature of Objective-C it only loaded the classes once. I'm
looking now for a way to prevent this. Does anyone have any idea how
to best deal with this ?
Do you have to include the toolkit in the plugins? There are ways
how one could have the plugin toolkit in the host application, or in a
framework, and have all the plugins dynamically link it in. If you
keep the size of the instance variable area constant (e.g. by using a
pointer to a struct to hold all ivars, or a dictionary if performance
is not an issue), they can even subclass your toolkit classes and
modify their behaviour that way. That would be much cleaner and is
what OOP was actually designed to allow. At least you would no longer
have to worry about namespace collisions among your toolkit classes.
On 15.02.2008, at 10:42, Lieven Dekeyser wrote:
Use class name prefixes as a simple namespace substitute. That's why
Cocoa class names are prefixed with NS ( see "Prefixes" in http://www.stepwise.com/Articles/Technical/2002-10-13.01.html
).
Well, nobody wants to edit the whole framework to have new prefixes,
but this is a common convention in Cocoa and will thus automatically
be used for the plugin developers' classes. For the framework, you
could achieve the same if you #define your toolkit's class names to
something unique for each build. You could e.g. have a shell script
build phase as the first phase in your project that generates a header
file that generates unique names for your classes, like:
#define ASToolkitWindow ASToolkit_JeffsPluginProject_Window
etc., maybe even append some other unique data to the names (bundle
identifier from the Info.plist?). Then include that header in all your
files and they'll "rename" the framework, and each plugin will get
their own copy. I did the same for some utility classes when I wrote
Cocoa Xcmds for SuperCard, though since we were talking only two
classes and three projects, I wrote the header manually there. Of
course, dynamically renaming classes this way means anyone trying to
use NSClassFromString() on such a class will fail, which includes
specifying one of these classes as the main class of your bundle.
Of course, with both approaches, the user's classes still have to be
uniquely named. If two guys have a PluginDelegate class, it'll still
break. A venue to investigate would probably be NSBundle - I think it
can give you a list of all classes in a bundle. So, you could probably
get a list of all classes, look at the bundle's class list (not sure
whether that would require loading it, though), and if any of the
names are the same, quarantine the newly-loaded plugin and bail,
telling the user which plugins collided, and telling them how to
exchange the one colliding plugin for the other, if the one you threw
out was more important to them than the one you had already loaded.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden