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 17:01:21 -0500
On May 21, 2005, at 4:24 PM, Bob Ippolito wrote:
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.
That's why all this mangling needs to be done in the macho
initialization routine - _before_ the runtime ever sees it (and from
that point on, it's just as consistent as if it always had that new
name).
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.
That is, of course, the best solution.
Perhaps a fair compromise would be to provide a "name spacer" tool
that takes a macho file, and a list of classes to make "private" and
then produces a new macho file updated so that all of those classes
have names that include uuids (though dynamic NSClassFromString would
still be problematic if the string were generated at run time - you
could fix literal Objective-C string constants for the new name,
though).
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