When one does need dynamic typing, it becomes tremendously powerful. Consider a simple example, placing an object in a container. In strongly-typed languages like C++ and Java, the programmer is forced to write a container class for a generic type of object, and then cast back and forth between the abstract generic type and the real type (C++ can also use templates, but many find these somewhat cumbersome and obscure). Sadly, casting breaks the discipline of strong typing -- if you put in an Integer and read out a String, you get an error. This is annoying when you consider that it was a string when you put it in there three lines earlier, and now you have to tell the compiler that it is a string coming back out just to call toUpperCase(). Dynamic typing thankfully removes this problem.

2.5 Categories

Cox's main concern was the maintainability of large code bases. Experience from the structured programming world had shown that one of the main ways to improve code was to break it down into smaller pieces. Objective-C added the concept of Categories to help with this process.

A category collects method implementations into separate files. The programmer can place groups of related methods into a category to make them more readable. For instance, one could create a "SpellChecking" category "on" the String object, collecting all of the methods related to spell checking into a single place.

That might not sound like anything new, but one key aspect of the implementation is that the methods are added to the class at runtime. That means that the programmer can add categories to existing classes without them knowing about it. If the system you are supplied with does not contain a spell checker in its String implementation, you just add it.

Combining categories with dynamic typing produces a synergy that results in tremendous flexibility that is largely unexpected in most programming systems. Consider Java: simply allowing String to have a checkSpelling method added isn't enough on its own, because the rest of your program won't allow you to call that new method - all methods must be known at compile time as a side effect of strong typing. Instead you must use helper objects, special proxy classes, or use the terrible visitor pattern, all of which add to the complexity and ugliness of the implementation.

But the usefulness of categories goes further. Since any method can be "covered" by one in a category at runtime, you can in fact fix bugs in existing compiled binaries. Once you get used to having this, you can't live without it.

A number of other languages have attempted to add this feature in a variety of ways. TOM took the Objective-C system to its logical conclusion and allowed for the addition of variables as well. Other languages have instead used prototype oriented solutions, the most notable being Self.

3 Other features

Objective-C in fact included a laundry-list of features that are still being added to other languages, or simply don't exist at all. These led from Cox's (and later, NeXT's) realization that there is considerably more to programming than the language. The system has to be usable and flexible as a whole in order to work in a real-world setting.

• Delegating methods to other objects at run-time is trivial. Simply add a category that changes the "second chance" method to forward the invocation to the delegate.
• Remote invocation is trivial. Simply add a category that changes the "second chance" method to serialize the invocation and forward it off.
• Swizzling allows for classes to change at runtime. Typically used for debugging where freed objects are swizzled into Zombies, whose only purpose is to report an error when someone calls them. Swizzling was also used in EOF to create database faults. Swizzling is used today by Apple's Foundation Framework to implement Key-Value Observing.
• Archiving. An object can be archived into a stream, such as a file, and can be read and restored on demand.

3.1 Objective-C++

Objective-C++ is a front-end to the Mac OS X version of the GNU Compiler Collection that can compile source files that use both C++ and Objective-C, with certain restrictions:

• A C++ class cannot derive from an Objective-C class and vice versa.
• C++ namespaces cannot be declared inside an Objective-C declarations.
• Objective-C classes cannot have instance variables of a C++ class type that has virtual functions, nor can C++ classes have instances of Objective-C objects.
• An Objective-C declaration cannot be within a C++ template declaration and vice versa, though Objective-C classes can be used as C++ template parameters.

4 Today

Objective-C today is often used in tandem with a fixed library of standard objects (often known as a "kit" or "framework"), such as OPENSTEP/ Cocoa/ GNUstep. These libraries often come with the operating system - the OPENSTEP libraries come with the OPENSTEP operating system and Cocoa comes with Mac OS X. One can however bypass the framework and inherit directly from the root object, Object, and create one's own functionality. The aforementioned libraries however implement NSObject, a more technologically advanced version of Object.

History note: Earlier versions of NeXT's NeXTSTEP operating system had objects inheriting from Object, but migrated to the newer NSObject root object, which was named to distinguish it from the original Object root (see Disadvantages below). All newer versions of the NeXTSTEP libraries which had objects inheriting from NSObject were prefixed with "NS", whilst those which did not inherit from NSObject did not. Later, the entire library codebase as OPENSTEP moved to use the NSObject class outright, and to maintain compatibility with the NeXTSTEP libraries, the prefix was maintained, and is still maintained in Cocoa today.

5 Analysis of the language

Objective-C is a very "practical" language. It uses a thin runtime written in C that adds little to the size of the application. In contrast most OO systems of the era used large VM runtimes that took over the entire system. Programs written in ObjC tended to be not much larger than the size of their code and that of the libraries (which often didn't have to be included in the software distribution ), in contrast to Smalltalk systems where you needed huge amounts of memory just to open a window.

Likewise the language was implemented on top of existing C compilers (first as a pre-processor, later as a GCC module) rather than as a new compiler. This allowed ObjC to leverage the huge existing collection of C code, libraries, tools, and mindshare. You can easily wrap existing C libraries - even in object code libraries - in ObjC wrappers to give them an OO style and more easily use them in your programs.

All of these practical changes lowered the barrier to entry , likely the biggest problem for the widespread acceptance of Smalltalk in the 1980s. In general Objective-C can be summed up as offering much of the flexibility of the later Smalltalk systems, in a language that is deployed as easily as C.

The first versions of Objective-C did not support garbage collection. At the time this was a matter of some debate and many people considered the long "dead times" when Smalltalk did collection to render the entire system unusable. ObjC avoided that problem by not including this feature. However in retrospect this is a serious oversight. Although some 3rd party implementations have added this feature (most notably GNUStep), Apple has not implemented it as of Mac OS X 10.3.

Another problem is that Objective-C does not include a namespace mechanism. Instead programmers are forced to add prefixes to their class names, a poor solution at best. Adding a namespace system would be simple and natural under ObjC (where they map onto the libraries system quite cleanly) so it is somewhat surprising this hasn't happened. As of 2004, all Mac OS X classes and functions from the Cocoa programming environment are prefixed with "NS" (as in NSObject or NSButton) to clearly identify them as belonging to the Mac OS X core; the "NS" derives from the names of the classes as defined during the development of NEXTSTEP.

Since Objective-C is a strict superset of C, it does not treat C primitive types as first-class objects either. Finally, since the language was based on C compilers, it remains highly dependent on a header file to work well. This is an added complexity that is no longer necessary. Newer languages, such as Java, C#, and Python, use the concept of modules instead.

Objective-C does not support operator overloading (though it does support ad-hoc polymorphism), unlike the C++ language. Unlike C++ also, but like Java, Objective-C allows an object only to directly inherit from one class (forbidding multiple inheritance). Categories and protocols may be used to provide many of the benefits of multiple inheritance, without many of the disadvantages, such as extra runtime overhead and binary incompatibilities.

6 External links

• The Objective-C Programming Language (pdf)
• Steve Dekorte Objective-C page
• The Objective-C++ Front End
• Beginner's Guide to Objective-C

• ObjectiveLib -variant of a Standard Template Library