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 14:24:28 -0700
On May 21, 2005, at 2:15 PM, glenn andreas wrote:
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).
The right solution with today's runtime is at compile time, the Obj-C
runtime and software that takes advantage of it makes certain
assumptions about the object and class protocols and this sort of
runtime mangling makes some of the assumptions false.
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?
Don't do that.
-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