I’ve been noticing a disturbing trend lately.
A friend asked me recently, “Would naming your own Objective class prefix with NS be an issue with Apple or that is just not good in general?”.
An industry luminary retweeted an otherwise useful macro:
#define CFAutorelease(cf) ((__typeof(cf))[NSMakeCollectable(cf) autorelease])
And recently I saw a blog post where they make their own CLLocationCoordinate2DMake, and then go through contortions to fix things when Apple introduced their own version in a later SDK.
Don’t do this! Stay out of Apple’s Namespace.
There are two big reasons to do this:
- Apple changes things. Often. If you add a function, macro, class, or struct in their namespace, you may break. People who use your code may break. People who cut and paste your tweets may break.
- It’s confusing for the person reading your code 3 years from now. Or your new hire. Or someone who uses part of your open source library. Or you include it into a posting on a mailing list or stack overflow. “CFAutorelease, I didn’t know that existed.” “uh, sorry, it really doesn’t.”
In general, you should stay out of the namespaces of any code you’re using, such as making your own GTM-named classes if you’re using the Google Toolbox For Mac. That could break you the next time Google revs that library.
CF, NS, CLLocation, etc. Those aren’t your playground.
That’s Apple’s turf. Which kind of makes me sad, since I’m doing stuff for Cycling Fusion now, and using the obvious prefix would be a disaster.
Pick your own prefix and use that. BWCFAutorelease, BWCLLocationCoordinate2DMake. This shows that yes, this is not part of Apple’s API, but also clearly shows the intent of the symbol. Without you being broken by Apple in the future.