What is the best way to solve an Objective-C namespace collision?

[SeoxyS]

This situation is most commonly encountered on iOS, with ad networks and SBJson.

As the developer behind one of the ad network SDKs included in countless iOS apps, I struggled finding a good solution to this problem. Spoiler: there isn't one.

The good news is, while there were often collisions on SBJson; pretty much all versions of the version are compatible. For a while, we would compile our static library without the SBJson objects, and ship the library and SBJson separately.

Recently we decided to create our own fork of SBJson, and switch to using our own prefix, which allowed us to embed it in our library, and not worry about what other libraries were doing.

Note: another tricky gotcha with static libraries for iOS: There is a bug in the linker, in that it will not import Objective-C categories from `.o` files unless there is another another symbol that is recognized, such as a class of C function. This has caused crashers and much headache.

[krevis]

About that category issue: you know about the -all_load and -force_load linker flags, right?

c.f. the "Important" box in http://developer.apple.com/library/mac/#qa/qa1490/_index.htm...

[thought_alarm]

Namespaces don't really solve that problem, do they?. Your options are to either fork SBJson and give it its own namespace/prefix, or require SBJson as an external dependency and lets your users provide their own version of the framework.

[buddydvd]

I'm not sure how well this works, but Nimbus (iOS framework) lets you embed itself in your own static library with a custom prefix via preprocessor macros. It would helpful if more libraries provide this feature.

http://wiki.nimbuskit.info/Nimbus-Namespacing

[barumrho]

This file seems to do the trick. Using macros to override class names. https://github.com/jverkoey/nimbus/blob/master/src/core/src/...

[sjmulder]

A month ago, Kyle Sluder proposed a namespacing system for Objective-C[1]. There has been a lively discussion both in the comments and on the objc-language mailing list[2].

1: http://www.optshiftk.com/2012/04/draft-proposal-for-namespac...

2: http://lists.apple.com/archives/objc-language/2012/Apr/msg00...

[aufreak3]

This is interesting, but doing it all at the compiler and language level seems like overkill. ObjC is a dynamic language, so the important thing is to have namespacing support in the runtime. If the user of a framework or bundle can specify a (reified) namespace to load a bundle's classes/protocols/etc and the runtime and language support A.B.C style class and protocol names, that might be enough to solve name collision problems. The framework/bundle author need not then bother to find a suitable globally unique name. This would certainly be enough to solve the original poster's problem.

I'm not sure I've thought through all issues with the above approach, but the whole @namespace thing seems gross overkill to me.

[cageface]

As ugly as C++ namespace mangling is, it does seem preferable to the kind of hacks it takes to solve this problem.

On the other hand, with a carefully chosen three letter prefix these kinds of collisions should be pretty rare in practice.

[_3u10]

Java/C# solve this problem, yet in those languages it's possible for one compiler's code to link with another.

Namespace mangling and more importantly a lack of standard for it are not required to implement namespaces.

In Obj-C it really wouldn't be that difficult to make an @namespace directive that just prepended the namespace to the class.

  @namespace com.apple.foo
  @interface Bar : NSObject
  @end

Could be semantically equivalent to

  @interface com_apple_foo_Bar
  @end

[pjmlp]

Funny how Apple still relies on language without any form of namespace support for their system.

Prefixes are not a solution as they have no ways to avoid collisions.

So much for supporting large scale development with Objective-C.

[to3m]

Are collisions that common?

I've never used namespaces in C++, and they aren't supported in C. And yet the only collisions I've seen between libraries are from un-prefixed identifiers. There's a whole pile of them in the Win32 headers of course. I ended up with a variable called "compress" once, in a function that was calling zlib. And Bink has a U32 or u32 typedef that conflicted with the same one in the code I was working on at the time.

Aside from that, no problems noted - of course, I cannot claim to have seen every program ever, and it is straightforward to engineer problems cases. But if a namespace collision is somehow news, you may assume that they are rarer in practice than you might imagine.

[batista]

>Funny how Apple still relies on language without any form of namespace support for their system.

Yeah, very funny, especially since they don't have any other pragmatic reasons to use it, ie. it being a more dynamic OO C than C++ while retaining full C power, them having huge API libraries for it over 25 years of NeXT/OS X development, etc etc.

>Prefixes are not a solution as they have no ways to avoid collisions.

It's not like you use lots of third party libs (if any at all) in OS X.

>So much for supporting large scale development with Objective-C.

Yeah, I mean they have just those tiny projects in it, like iPhoto, Final Cut Pro, Pages, Numbers, the whole Cocoa and Cocoa Touch stack, etc.

But we need more support for large scale development, because there are many many teams of 100s of programmers that also want to write 20 million lines Objective-C programs.

And C is even worse, you just have small projects like the Linux kernel written in it, due to the severe issue of lack of namespaces.

/s

[astrange]

Despite the accepted answer saying to use bundle unloading, please don't. It may be supported in theory but in practice unloading a bundle leaves all kinds of opportunities for stale pointers and crashing.

[SoftwareMaven]

As much flak as Java gets, at least they got namespaces right. Python got better, but it's still not what I would call great.

[fleitz]

At first glance yes, but as always with Java when you dig under the hood you see tight coupling to bad ideas from the early 90s. Given the OO/Java mantra of decoupling I'm not sure why the namespace is a consequence of the filepath they seem far too tightly integrated.

[masklinn]

Haskell's hierarchical modules extension is also very, very good. Amongst other things, it fixes Python's issue of lacking independent "namespaces" (mapping namespaces to packages or modules directly means you can't have two packages living in the same namespace easily)

Still has one failure though: the default import is both qualified and unqualified, I think it should have been qualified only.

[pjmlp]

Any language with namespace/modules support has this right.

Only C and Objective-C don't, and force everyone to come up with prefixes.

And when collisions do happen, you have to resort to preprocessor tricks to work around it.