Problem with NSMutableString global

Question

Hi all,
I'm having problems creating a global string that I can access and change as needed. I start by defining a mutable string in the header file like this...
/* AppController.h */
#import <Cocoa/Cocoa.h>
extern NSMutableString *testString;
@interface AppController : NSObject
<snip>
<snip>
@end
then declare it in the main file like this...
// AppController.m
#import "AppController.h"
NSMutableString *testString = @"Hello string!";
@implementation AppController
<snip>
@end
Now, I don't have any problem displaying my simple "Hello string!" message in an NSTextField with:
[nameField setStringValue:testString];
but as soon as I try to change the fixed text to something else, using:
testString = [addressField stringValue];
or (even worse) using a direct assignment like...
testString = anotherString;
[nameField setStringValue:testString];
then try to display it in the NSTextField using the previously successful code line, the compiler will generate errors (usually 'warning: assignment from distinct Objective-C type' or the even more confusing 'trying to mutate an immutable object') or the app will hang
I'm obviously making a very fundamental error here, and I've searched the developer documentation and the net for info on this without any success. And possibly because the problem is so dumb and so basic that no-one even bothered to write it up yet... Can anyone tell me where I'm going wrong and how to achieve what I'm trying to do, please?
Ernie

Answer 1

Hi PsychoH13,
First of all, you shouldn't use global variables. It's highly unadvised... So, don't use global
variables.
I agree that while it would be dumb to give every variable global scope (an extreme example), it surely is legitimate programming practice to use globals if the alternative would be say, to sacrifice simplicity by writing blocks of complex code to achieve the same goal.
In the early programming days, there was a good argument to be made for avoiding globals whenever possible, in order to make best use of limited available memory in those older computers. But memory isn't really an issue with modern hardware nowadays -- yet the same 'rule' seems to have carried over to the present day.
Personally I feel it's all a balancing act depending on the situation at the time. On the one hand, it's true we might violate the rule of least privelege. But by avoiding global scope under every circumstance, we then violate a principle of simplicity and have to write heaps of extra code to hang on to, and repeatedly pass the variable to where it's needed. And the more complex the code, the more likely we are to introduce errors, and the harder it becomes to read if/when we need to fix problems...
Other arguments in favour of globals are (2) while we might use up a few extra bytes permanently hanging on to a global variable while the app runs, not using them means the app itself must become permanently bigger to accommodate our extra lines of code, and (3) since globals are a legitimate part of the official 'C' standard, why not make use of them (sparingly, of course) ?
And it seems many big-league programmers feel the same. In Aaron Hillegass' book "Cocoa Programming For Mac OS X" he uses two globals in his preferences pane example, and says (quote):
"...you could use the C pre-processor's #define command, but most Cocoa programmers use global variables for this purpose. Add the following lines to your PreferenceController.h file after the #import statement:
extern NSString *BNRTableBgColorKey;
extern NSString *BNREmptyDocKeyKey;
"(end quote).
So -- other than the fact that all Americans seem to have a major problem spelling the word 'colour' correctly -- I don't feel qualified to go against that and agree with the view that 'all globals == always bad'.
Second of all, in Objective-C, it's not because you declare a variable as being a NSMutableString
that it will be an NSMutableString. The type is determined at runtime and by the object that you
assign. Here, a Objective-C string literal like this :
@"my string"
Is totally immutable, so if you try using methods of NSMutableString it won't work.
Oh... okay... I see... <blink, blink>. Just when I thought I was cruising along with my Cocoa conversion, seems like I've just stepped on another conceptual land-mine about immutable strings literally being 'read-only' and mutable strings being 'read-write'. The issue was made even more confusing by the fact that I can alter a locally-declared mutable string in my test app without problem, but the same technique falls down when applied to strings with global scope.
So, assuming you yourself needed a string that you could change frequently -- but still needed global access to it -- any tips on how'd you go about it, please?
Thanks!
Ernie