What is the best way to define string constants in an objective-c protocol?

Question

I have defined a protocol that all my plug-ins must implement. I would also like the plug-ins to all use certain strings, like MyPluginErrorDomain. With integers this is quite easily achieved in an enum, but I can't figure out how to do the same with strings. Normally, in classes I would define

extern NSString * const MyPluginErrorDomain;

in the .h file and in the .m file:

NSString * const MyPluginErrorDomain = @"MyPluginErrorDomain";

but that doesn't work very well in a protocol, because then each plug-in would have to provide its own implementation which defeats the purpose of having a constant.

I then tried

#define MYPLUGIN_ERROR_DOMAIN @"MyPluginErrorDomain"

but the implementing classes in the plug-in can't seem to see the #define. Who knows a good solution?

Answer 1

You can declare them in the header with the protocol (but outside the protocol interface itself), then define them in an implementation file for the protocol (obviously it wouldn't have an @implementation section - just your NSString definitions).

Or have a separate .h/.m pair that is just for the string constants (the protocol header can import the string constants header).

Answer 2

In C++, I would declare them in a header like this:

const char * const MYPLUGIN_ERROR_DOMAIN = "MyPluginErrorDomain";
const char * const MYPLUGIN_FOO_DOMAIN = "MyPluginFooDomain";

Note that as the pointers are const, they will be local to the translation units the header is #included in, and so there will be no need to use extern to prevent multiple definition errors.

Answer 3

You keep the .h definition:

extern NSString * const MyPluginErrorDomain;

but put this part into a separate .m file that gets included in your framework:

NSString * const MyPluginErrorDomain = @"MyPluginErrorDomain";

So plug-ins can still implement the interface but when compiling they link or compile in your other .m file, so they will see the value of MyPluginErrorDomain.

Answer 4

You should implement it as extern strings as in your example:

extern NSString * const MyPluginErrorDomain;

or provide extern functions which return static storage data. For example:

 /* h */ 

 extern NSString * MyPluginErrorDomain();

 /* m */ 

 NSString * MyPluginErrorDomain() {
    static NSString * const s = @"MyPluginErrorDomain";
    return s;
 }

The reason is that strings and keys are often used and compared by pointer value or hash value, rather than true string comparison (isEqualToString:).

At the implementation level, there is a big difference between:

In code, that means that when the strings compared are defined in multiple binaries:

Say 'MyPluginErrorDomain' and 'key' have identical string values, but are defined in different binaries (i.e. on in the plugin host, one in the plugin).

/////// Pointer comparison (NSString)
BOOL a = [MyPluginErrorDomain isEqualToString:key];
BOOL b = MyPluginErrorDomain == key;

// c may be false because a may be true, in that they represent the same character sequence, but do not point to the same object
BOOL c = a == b;


/////// Hash use (NSString)
// This is true
BOOL d = [MyPluginErrorDomain hash] == [key hash];

// This is indicative if true
BOOL e = [MyPluginErrorDomain hash] == [someOtherStringKey hash];

// because
BOOL f = [MyPluginErrorDomain isEqualToString:someOtherStringKey];

// g may be false (though the hash code is 'generally' correct)
BOOL g = e == f;

It is therefore necessary to provide the keys in many cases. It may seem like a trivial point, but it is hard to diagnose some of the problems associated with the difference.

Hash codes and pointer comparisons are used throughout Foundation and other objc technologies in the internals of dictionary storage, key value coding... If your dictionary is going straight out to xml, that's one thing, but runtime use is another and there are a few caveats in the implementation and runtime details.