Re: Strategy for using common classes in multiple Cocoa plug-ins?
Re: Strategy for using common classes in multiple Cocoa plug-ins?
- Subject: Re: Strategy for using common classes in multiple Cocoa plug-ins?
- From: glenn andreas <email@hidden>
- Date: Sat, 21 May 2005 16:15:50 -0500
On May 21, 2005, at 3:58 PM, Bob Ippolito wrote:
On May 21, 2005, at 1:18 PM, glenn andreas wrote:
On May 21, 2005, at 12:39 PM, Andy Lee wrote:
On May 21, 2005, at 1:18 PM, Mark Munz (DevList) wrote:
In an earlier discussion, it was pointed out that Cocoa classes
all share the same namespace per process. The problem I'm
realizing is that I have some common utility classes that I'm
using that are used in several plug-ins (and will be sharing the
same space).
I'm wondering what the best strategy for dealing with this issue
is in writing these plug-ins?
If you own all the code for those common utilities, I would
suggest the low-tech approach of giving the class names a short
prefix that isn't likely to be used by someone else. This not
only helps prevent the namespace problem, it can help indicate
groups of classes that belong together. The Omni frameworks, for
example, each use a different prefix for class names.
For a high-tech approach (in theory - never actually tried this),
you could write an initialization routine that is called when the
framework is loaded which walks through the macho sections (not as
hard as it seems, BTW) to find all the Objective-C classes and
changes the names of your classes (by changing the name pointer in
the class and meta-class structures) to a "random" name (or at
least one that hasn't be used yet). This would assume that you
don't do anything like NSClassFromString, though, and still would
require a unique name for the principal class (since that's in the
plist, and if you change the name, it won't be found). In theory
this could work, since the initialization routine is called "after
initializing any static variables but before calling any other
functions or methods in your framework" (which hopefully means
"before calling the Objective C runtime to load your classes"
since otherwise the +initialize routines would be called).
Wow that sounds like a bad idea.
Why? Until there is some clean provision for subdividing the
Objective C class name space, the only way to avoid class name
collisions is to either avoid it at compile time (with unique names)
or at run time (by changing the names of the classes).
You could create a framework or bundle containing your utility
classes, and load it only if you can't already NSClassFromString
(...) the classes in it. Of course, this means you have to use
NSClassFromString everywhere... but at least you wouldn't be
breaking the rules.
How is this going to help in the case where two plugins both have
different utility classes (or at least different versions) with the
same name?
Glenn Andreas email@hidden
<http://www.gandreas.com/> oh my!
quadrium | build, mutate, evolve | images, textures, backgrounds, art
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden