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.

Advertisements

Related

Lucky for Cocoa developers there is an informal place to ‘register’ your prefix. If you write code that goes into the public space you should stake a claim to your prefix over at cocoadev.com . Then you have a better chance of people not colliding into ‘your’ namespace.

Actually, as of WWDC ’10 at least, Apple’s official recommendation is that you don’t use *any* two-letter prefixes in your code, in case Apple decides to release a new framework that stomps on your prefix that way. This is mentioned in the WWDC Session 130 video, I don’t know if there’s a documentation release that mentions this or not.

I think expecting us to avoid all two-letter prefixes isn’t realistic. I also think that’s much less of an issue than from the outset intentionally naming functions to look like Apple calls. I have GRWorkout and GRHeartRateMonitor classes, which I doubt Apple will be duplicating.

You can file this under interesting but useless but it’s a little disheartening to still have this problem when there are other tools that support namespaces. I’m having flashbacks to the days of kilometric identifiers because we had one global namespace.

I wouldn’t call it “useless” since violation of Apple’s namespace can have a non-trivial, negative impact in the future. Yes it’s sad we don’t have better tools in this respect, but for right now it’s what we have.