0

For example, why use this:

NSLocale *l = [[NSLocale alloc] initWithLocaleIdentifier@"en_US"];

Instead of something like this:

NSLocale *l = [[NSLocale alloc] initWithLocaleIdentifier:NSLocaleIdentifierUS];

It seems like it would prevent a lot of errors, as when typing an NSString in Xcode, there is no autocorrect, while Xcode will autocorrect/autofill enums. Additionally, I can't think of a reason to use NSStrings over enums or constants. For example, as new versions of the SDK are released, Apple can add new identifiers, but they can also do this with enums. Another benefit of enums over string constants is that enums can be compared more easily:

if(userIdentifier == NSLocaleIdentifierUS) {

    //English!
}

Also, for other methods, Apple uses enums or specific objects as parameters:

NSData *data = [aString dataUsingEncoding:NSASCIIStringEncoding];

If they use a string for localeIdentifier, why not do this:

NSData *data = [aString dataUsingEncoding:@"ascii"];

It seems like they are simply being inconsistent.

pasawaya
  • 11,515
  • 7
  • 53
  • 92
  • I think it's because those are ISO standards not defined by apple so they want you to be familiar with them. – mkral Oct 17 '12 at 23:16
  • That's probably right, since it is a standard a lot of web services will use them, so it saves you the trouble of parsing it into an enum when you receive it as a string. – borrrden Oct 17 '12 at 23:19
  • Also there are hundreds of locales. There are many just for **en**. Plus all of the variants such as **en_US_POSIX**. And the list of locales changes over time. It would be tough to have so many enums with more added all of the time. – rmaddy Oct 17 '12 at 23:39
  • I have to agree with mkral and rmaddy. I'm sure that Apple has just too many keys that they use and didn't bother to define the generic or external definitions. They may have built a lot of their code, or reused existing code that already checked for a string value, rather than Apple defined enums. Those reasons are cause enough for them to let it be. – RileyE Oct 18 '12 at 00:50
  • Another possible reason is that strings are objects, and can therefore be stored in objective-c collections without wrapping them. – ughoavgfhw Oct 18 '12 at 00:53
  • These are all excellent answers. Would you mind if I combined all of them into a single community wiki answer? – pasawaya Oct 18 '12 at 00:55

1 Answers1

0

There are several answers to this question suggested by the comments:

  1. There are hundreds of locales, and many variations of the ones that already exist (ex. there is "en_US" and "en_US_POSIX", so it would be impractical to create this many enums.
  2. When reading data from a web service, the format used is "lang_COUNTRY", so it would make sense to have the same format to avoid having parse web data every time one downloaded locale data from the web.
  3. Strings are objects, so they can easily be stored in collections without wrapping them in an NSNumber object, as would be the case with enums.
pasawaya
  • 11,515
  • 7
  • 53
  • 92