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: Ricky Sharp <email@hidden>
- Date: Tue, 5 Sep 2006 16:54:02 -0500
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