Re: Strategies to prevent class name clashes
Re: Strategies to prevent class name clashes
- Subject: Re: Strategies to prevent class name clashes
- From: Arne Scheffler <email@hidden>
- Date: Fri, 15 Feb 2008 12:42:57 +0100
Hi Uli,
the toolkit in question is VSTGUI. It's a C++ cross-platform UI
library. It is statically linked into every plug-in. Mostly the users
of it won't use Objective-C by them self.
The problem I did face was that I have an ivar which is a C++ class of
the lib. And when I used this ivar and the C++ object had a different
layout than at build time it crashed. Here's an outline of what I mean :
class CFrame
{
public:
//...
};
@interface VSTGUI_NSView : NSView {
CFrame* _frame;
}
- (id) initWithCFrame: (CFrame*) frame;
@end
It crashed inside initWithCFrame because CFrame did change because one
of the plug-in used a newer version of the lib.
It seems like I'm out of luck if I'm going this route.
After thinking about it a while I think I need to write C functions
which will interact between the C++ class and the Objective-C class.
After all this Cocoa change is a headache for plug-ins.
thanks
arne
On Feb 15, 2008, at 11:43 AM, Uli Kusterer wrote:
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