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: Andrew Merenbach <email@hidden>
- Date: Tue, 5 Sep 2006 16:38:10 -0700
As a suggestion to future readers and an augmentation to this idea
(although I'm not sure of how else one would do it, anyway), I
suppose that an organised way of setting this up would be to use a
prefix that involves the version number somehow:
#define AMPrefPaneClass AMPrefPaneClass_v101_AM
or something like that; then, in a future version,
#define AMPrefPaneClass AMPrefPaneClass_v102_AM
and so on.
Cheers,
Andrew
On 5 Sep 2006, at 15:59, Andrei Tchijov wrote:
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:
40ucla.edu
This email sent to email@hidden
_______________________________________________
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