Does Objective-C need Namespaces?

This one comes up every second week or so. Namespaces would indeed be a minor convenience, and useful for cases like loading plug ins. I myself have suggested a low-impact mechanism for implementing them ( http://lists.apple.com/archives/objc-language/2007/Jan/msg00023.html ). The problem, though, is that class name conflicts are rare and obvious when they happen, but in a dynamic language like ObjC method conflicts are a real problem, since superclasses or categories can effectively add methods at any time. The results of such conflicts tend to be subtle and lead to the tearing-out of much hair. Defining an elegant mechanism that avoids this while still allowing you to use a version of a method that you didn’t know about at build time, without completely redesigning the language (serious runtime changes would be a given) appears to be an unsolved problem.

Quite true. The balancing act between keeping ObjC as dynamic as it is right now (being able to send messages to objects at runtime without knowing at design-time if such a message can be passed, as well as dynamically changing responder chains at runtime) while adding the naming security of namespaces is a tough one. Sure, namespaces would be nice - but only if they can be had without harming ObjC as it exists today.

Kevin, I've been enjoying this series of posts quite thoroughly. I'm a C# junky too, but have been quite tempted by your posts to try Objective C 2.0 as well. Alas, it will have to wait until after I master Lisp and Haskell . . . In any case, I wanted to chime in on my belief in the importance of namespaces. I'm a big believer in DDD and just wanted to note that Evans makes a point that namespaces can be very helpful in making the domain model much more "explicit" (aside from just preventing naming conflicts).

Totally agree. Namespaces are about readability, explicitness, and clean-looking code. It's a handy side-effect that they can be used for naming conflicts as well. I'm hoping that Apple will eventually find some way to deal with the method name lookup issues present in namespaces w/Objective-C and give that to us as an option. For example, Garbage Collection is going to be an optional compiler flag... It'd be nice if I could also optionally compile my app to use namespaces.

On the other hand, it can be a little confusing if the class has the same name as one in another namespace and it's not clear which it is. That isn't a problem when the distinction is in the classname itself.

At least Objective-C uses somewhat meaningful prefixes. Delphi's pascal had a convention where all classnames should start with 'T' (ie, TFoo, TBar, TView, TForm). But not all constructs with a T were classes. So the T was a fairly useless appendage.

Another thought. Objective-C gets some abuse because of the verbosity of the method names, but Java can be quite annoying with the length of the fully-qualified class names. At least SSTableView is concise... ;^) Even JonHendryTableView is concise compared to com.sun.java.foo.bar.grids.TableView.

And when properties use a similar pattern... whoo boy, reading logs is a treat.

I hear you on the "T" prefix from Delphi... I hated that :)

I love the verbosity of invoking methods in Objective-C, its extremely easy to read.

Namespaces are a lot like something else you won't see in ObjC: operator overloading. While in *theory* it sounds like a good idea, practices in the real world seems to conspire against it. Just as I don't like to see a bit of code like "a + b" and have to go searching to see if that accomplishes addition or string concatenation (or maybe even something more esoteric), I don't like to see "Person" and constantly concern myself about what what of many possible classes it refers to.

Also, frameworks can be used to group classes in such a way that it accomplishes what namespaces do. For example, even though NS is supposed to be NextStep pseudo-namespace, you could replace them all without changing your code simply by changing the Cocoa include statement to that of a framework of your own design with the same classes. I believe that is essentially how GNUstep works behind the scenes.

When I was first introduced to ObjC&Cocoa, I suddenly realized that they had no name spaces. Coming from academic Java at that time, I was stumbled that this system could exist without it. My "instructor" assured me that there never have been problems with everone following NeXT with a class name prefix (as you mentioned above).

7 Years of Cocoa later, I can second his point. Like generic types (C++, Java) explicit name spaces would solve a non-problem in Cocoa.

That's an excellent point... Namespaces would solve a non-problem in Cocoa. Very well put.

In my experience the main problem with the prefixes is coming up with one that is aesthetically pleasing.

;^)

I'm a c++ developer and I appreciate the extra flexibility in design allowed by namespaces in c++. It would be nice to have it in objc if it is technically feasible.

Not only does the verbosity of ObjC comments make them easier to read, so does the inline-argument thing... - might look in some other language like MyClass.foo(a,b,c), with only useful variable names to guide us.

Long time listener, first time caller. And as a Mac user, I have to say, "Joooiiiiiiin usss." Kidding aside, namespaces might be nice, but it'd be something to thoroughly think through.

One advantage that Obj-C has over C++ and Java is that it's a complete superset of C. "int public=5;" will compile in C. It will compile in Obj-C. It errors out in C++ and Java. That's why all the Obj-C keywords are either in brackets (Thus, won't be valid C anyways) or start with @.

There's a hint of a namespace in bundles, whatwith com.yourcompany.yourapp.plist in the preferences folder. But namespaces have these cons: It doesn't solve the method problem mentioned by others, it could be an awkward mess to use, It carries the danger of finding the right keywords, and the biggest one is that it can obfuscate things.

To a great degree, you can work on an Obj-C function and only keep the mindset of the scope of the function. If you have a namespace declaration at the beginning of the file, that's one more state to keep in mind that might have significant effects. Ironically enough, perhaps the biggest reason against namespaces is that it leads to name conflicts not in the compiler, but in the programmer's head. Besides, the naming conventions for classes and variables and the like is kind of cute.

Also, something that really goes counter to namespaces. Cool and scary at the same time. PoseAsClass if you haven't seen this.

This is very after the fact, but...

I can present a compelling argument for namespaces in Objective-C (or any language that has ambitions to being used on large systems): As systems get larger and more vendors start providing more toolkits, sooner or later you are guaranteed to have name conflicts. The post mentions class name conflicts, but variable and constant name conflicts are just as problematic. As one comment has noted, so far, this is a non-problem for Objective-C, but I will argue that is only true because Objective-C has essentially only one vendor on one platform.

Let me give an example: Years ago, I had to take a GUI app that had been developed using Borland's OWL toolkit and extend it using Borland's new C++ Builder toolkit. Many of the classes in the two toolkits had the same names, but because I could wrap the old toolkit in a C++ namespace, I was able to keep them separated. Unfortunately, there were also many constants that were defined in both toolkits using the C preprocessor, and those were all namespace independent. This led to many very subtle bugs, and a very complicated build process designed to separate the two source trees as much as possible to avoid conflicts.

Objective-C is vulnerable to these kinds of conflicts, and has protections against neither. The only defence is strict programmer discipline, like: munge your own namespaces by prefixing MyToolKit to all of your class, variable and constant identifiers, and never, ever use the preprocessor to define anything but cross-platform conditional compilation blocks.

At the moment, there are few enough Objective-C toolkit vendors so that this sort of discipline is commonplace and expected. If the history of C and C++ is relevant at all, we can expect that this will not remain true if the platform grows at all. Just think: the best practice suggested in the post was for Super Soft to call their classes SSWhatever. But what happens when Solid Systems puts out a competing library? How will you distinguish between SSCanvas and SSCanvas? If namespaces are available, you could wrap each library in its own namespace and keep them separated. Without namespaces...well...what would you do?