Re: Is it possible that PreferencePane's share "classes name space"?
Re: Is it possible that PreferencePane's share "classes name space"?
- Subject: Re: Is it possible that PreferencePane's share "classes name space"?
- From: Andrei Tchijov <email@hidden>
- Date: Tue, 5 Sep 2006 18:59:26 -0400
Rick,
As I indicated in my original post, I went along "way number 1".
Though I did not actually went on renaming classes, I just used
"#define <class name> <new prefix><class name>" in <class name>.h
file.
Andrei
On Sep 5, 2006, at 5:54 PM, Ricky Sharp wrote:
On Sep 5, 2006, at 4:33 PM, Andrei Tchijov wrote:
This is what I am observing (though I can not believe my eyes). I
happen to have two versions of my Preference Pane which I would
like people to be able to use at the same time. Though newer
version is almost complete re-write, there are 1 or 2 classes
which share it names between old version and new version. What I
observe is that if I "open" old version of the pane, and than try
to open new one, I am getting error which indicates that new
version trying to use classes from old version. If I start new
version first, than I can not run old version because it is trying
to use newer version classes ( there are some methods which
present on old but not new and other way around, so "unfortunate"
panel crash on "selector not recognized" ).
I can deal with this particular problem (by using #define to re-
name all "shared" classes in new version). What bothers me is the
fact that there is no ANY guaranty that I will not come up with
class name which is used/implemented by some other preference
pane. Am I missing something? Is there a way to FORCE preference
pane to look only inside itself when it is trying to resolve classes?
You comments on this subject will be highly appreciated,
See the previous thread (updated just today) with the subject
"strange situation with frameworks"
Short answer is that you can't have classes with the same name be
loaded more than once. I saw this same behavior a while back in IB
where I had two separate palettes attempting to load the same
classes (auxiliary inspectors common between palettes).
Now then, I would strongly recommend that you start out by ensuring
your class names (even method names) are all unique. What I do in
my own code is to prefix all class names, typedefs, key archiver
keys, and constants with my company abbreviation "II". I then
suffix all ivars, initial portion of methods, custom bindings, etc.
with "_II". This effectively puts all my code in its own namespace.
You then need to deal with your case where you're also conflicting
with yourself. Two things come to mind:
(1) Rename things to be unique in your new version.
(2) If the classes that are conflicting use some common classes
whose implementation is identical in both plugins, perhaps move
them to its own framework. Then, in your plugin loading code (I'm
assuming you have some sort of hook), ensure the framework is only
loaded once.
Either case, it sounds unfortunately like a lot of work. I'm not
too sure if (2) is even worth a look as that will fall apart the
instant that your newer version needs to change any of the
implementations in the common classes.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
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