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: Bob Ippolito <email@hidden>
- Date: Sat, 21 May 2005 13:58:32 -0700
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.
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.
-bob
_______________________________________________
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