Today it is used primarily on Mac OS X and GNUstep, two environments based on the OpenStep standard, and is the primary language used for the NeXTSTEP, OPENSTEP, and Cocoa application frameworks. Generic Objective-C programs which do not make use of these libraries can also be compiled for any system supported by gcc, which includes an Objective-C compiler.
In the early 1980s, common software engineering practice was based on structured programming. Structured programming was implemented in order to help "break down" programs into smaller parts, primarily to make them easier to work on as they grew increasingly large. However, as the problems being solved grew in size, structured programming became less useful as more and more procedures had to be written, leading to complex control structures and poor code reuse.
Many saw object-oriented programming as a potential solution to the problem. In fact, Smalltalk had already addressed many of these engineering issues: some of the most complex systems in the world were Smalltalk environments. On the downside, Smalltalk used a virtual machine. The virtual machine interpreted an object memory called an image, containing all development tools. The Smalltalk image was very large and tended to require huge amounts of memory for the time and ran very slowly, partly due to the lack of useful hardware vm/container support.
Objective-C was created primarily by Brad Cox and Tom Love in the early 1980s at their company Stepstone. Both had been introduced to Smalltalk while at ITT’s Programming Technology Center in 1981. Cox had become interested in the problems of true reusability in software design and programming. He realized that a language like Smalltalk would be invaluable in building powerful development environments for system developers at ITT. Cox began by modifying the C compiler to add some of the capabilities of Smalltalk. He soon had a working implementation of an object-oriented extension to the C language which he called "OOPC" for Object-Oriented Programming in C. Love, meanwhile, was hired by Schlumberger Research in 1982 and had the opportunity to acquire the first commercial copy of Smalltalk-80, which further influenced development of their brainchild.
In order to demonstrate that real progress could be made, Cox showed that making interchangeable software components really needed only a few practical changes to existing tools. Specifically, they needed to support objects in a flexible manner, come supplied with a set of libraries which were usable, and allow for the code (and any resources needed by the code) to be bundled into a single cross-platform format.
Cox and Love eventually formed a new venture, Productivity Products International (PPI), to commercialize their product, which coupled an Objective-C compiler with powerful class libraries.
In 1986, Cox published the main description of Objective-C in its original form in the book Object-Oriented Programming, An Evolutionary Approach. Although he was careful to point out that there is more to the problem of reusability than just the language, Objective-C often found itself compared feature for feature with other languages.
In 1988, NeXT, the company started by Steve Jobs after Apple, licensed Objective-C from StepStone (the owner of the Objective-C trademark) and released their own Objective-C compiler and libraries on which the NeXTstep user interface and interface builder were based. Although the NeXT workstations failed to make much of an impact in the marketplace, the tools were widely lauded in the industry. This led NeXT to drop hardware production and focus on software tools, selling NeXTstep (and OpenStep) as a platform for custom programming.
The GNU project started work on their free clone of NeXTStep, named GNUstep, based on the OpenStep standard. Dennis Glatting wrote the first gnu-objc runtime in 1992. The GNU Objective-C runtime which has been in use since 1993 is the one developed by Kresten Krab Thorup when he was a university student in Denmark. Kresten also worked at NeXT from 1993-1996.
After acquiring NeXT in 1996, Apple used OpenStep in its new operating system, Mac OS X. This included Objective-C and NeXT's Objective-C based developer tool, Project Builder (later replaced by Xcode), as well as its interface design tool, Interface Builder. Most of Apple's present-day Cocoa API is based on OpenStep interface objects, and is the most significant Objective-C environment being used for active development.
Objective-C is a very thin layer on top of C. Objective-C is a strict superset of C. That is, it is possible to compile any C program with an Objective-C compiler. Objective-C derives its syntax from both C and Smalltalk. Most of the syntax (including preprocessing, expressions, function declarations, and function calls) is inherited from C, while the syntax for object-oriented features was created to enable Smalltalk-style messaging.
Objective-C syntax offers alternatives to a few 'kludges' in C syntax but more importantly supports object-oriented programming. The Objective-C model of object-oriented programming is based on sending messages to sovereign (even self-correcting) objects. This is unlike the Simula programming model used by C++ and this distinction is semantically important. The basic difference is that in Objective-C one does not call a method; one sends a message. In Objective-C the 'receiver' of a message can opt to refuse it. Both styles carry their own strengths and weaknesses. Simula style OOP allows multiple inheritance and faster execution by using compile-time binding whenever possible but does not support dynamic binding by default. It also forces all methods to have a corresponding implementation unless they are virtual but still, cannot be called unless an implementation is given. Smalltalk OOP allows messages to go unimplemented and is dynamically bound (see Dynamic Binding) but in some cases runs slower and some programmers (especially ones from simula based languages) feel that it is a hassle to debug. On that note, some Simula style programmers hate Objective-C while Objective-C (Smalltalk style) programmers hate Simula style languages and feel that they are not "true" object-oriented languages or that they are severely flawed (notably, C++ is the most attacked: for more information, see C++ FQA Lite).
An object obj with method method is said to 'respond' to the message method. Sending the message method to obj would require the following code in C++.
Which in Objective-C is written as follows.
This mechanism allows messages to be sent to an object defined first at runtime - something statically typed languages such as C++ and Java are incapable of per the current standards for both languages. C++ will be able to support messaging per ANSI Standard if the Boost library is standardized. Qt provides this capability to both C++ and Java by adding the "connect" function as well as a large array of classes that afford and support this functionality. (Also See the dynamic typing section below for more advantages of dynamic (late) binding.)
Objective C has a few features in message passing that relates to how it handles OO. Objective C messages do not need to execute because they are dynamically bound. If a message is implemented by an object, it will execute, but if not, it will not execute, yet the code will still compile and run. So for example, Every object is sent an "awakeFromNib" message... but those objects don't necessarily have to implement "awakeFromNib" to compile, if an object does implement "awakeFromNib", then that code will be executed when the message is sent, otherwise the message is ignored. Messages can also be sent to the object that implements them or to the superclass that an object is derived from. These can be accessed using the "self" and "super" object pointers. also, messages can be sent to nil objects.
Objective-C requires the interface and implementation of a class be in separately declared code blocks. By convention, the interface is put in a header file and the implementation in a code file; the header files, normally suffixed .h, are similar to C header files; the implementation (method) files, normally suffixed .m, can be very similar to C code files.
The interface declaration of the form:
Plus signs denote class methods, minus signs denote instance methods. Class methods have no access to instance variables.
Return types can be any standard C type, a pointer to a generic Objective-C object, or a pointer to a specific type of object such as NSArray *, NSImage *, or NSString *. The default return type is the generic Objective-C type id.
Method arguments begin with a colon followed by the expected argument type in parentheses followed by the argument name. In some cases (eg when writing system APIs) it is useful to add descriptive text before each parameter.
Methods are written as with their interface declarations. Comparing C and Objective-C:
The syntax allows pseudo-naming of arguments.
Internal representations of this method vary between different implementations of Objective-C. If myColor is of the class Color, internally, instance method -changeColorWithRed:green:blue: might be labeled _i_Color_changeColorWithRed_green_blue. The i is to refer to an instance method, with the class and then method names appended, colons translated to underscores. As the order of parameters is part of the method name, it cannot be changed to suit coding style or expression as in true named parameters.
However, internal names of the function are rarely used directly, and generally messages are converted to function calls defined in the Objective-C runtime library - it's not necessarily known at link time which method will be called: the class of the receiver (the object being sent the message) need not be known until runtime.
Once an Objective-C class is written, it can be instantiated. This is done by first allocating the memory for a new object and then by initializing it. An object isn't fully functional until both steps have been completed. These steps are typically accomplished with a single line of code:
The alloc call allocates enough memory to hold all the instance variables for an object, and the init call can be overridden to set instance variables to specific values on creation. The init method is often written as follows:
Objective-C was extended at NeXT to introduce the concept of multiple inheritance of specification, but not implementation, through the introduction of protocols. This is a pattern achievable either as an abstract multiply inherited base class in C++, or else, more popularly, adopted (e.g., in Java or C#) as an "interface". Objective-C makes use of both ad-hoc protocols, called informal protocols, and compiler enforced protocols called formal protocols.
An informal protocol is a list of methods which a class can implement. It is specified in the documentation, since it has no presence in the language. Informal protocols often include optional methods, where implementing the method can change the behavior of a class. For example, a text field class might have a delegate which should implement an informal protocol with an optional autocomplete method. The text field discovers whether the delegate implements that method (via reflection), and, if so, calls it to support autocomplete.
A formal protocol is similar to an interface in Java or C#. It is a list of methods which any class can declare itself to implement. Versions of Objective-C before 2.0 required that a class must implement all methods in a protocol it declares itself as adopting; the compiler will emit an error if the class does not implement every method of its declared protocols. However, Objective-C 2.0 added support for marking certain methods in a protocol optional; the compiler will not enforce that such methods are implemented.
The Objective-C concept of protocols is different from the Java or C# concept of interfaces in that a class may implement a protocol without being declared to implement that protocol. The difference is not detectable from outside code. Formal protocols cannot provide any implementations, they simply assure callers that classes which conform to the protocol will provide implementations. In the NeXT/Apple library, protocols are frequently used by the Distributed Objects system to represent the capabilities of an object executing on a remote system. The syntax
denotes that there is the abstract idea of locking which is useful, and when stated in a class definition
denotes that instances of SomeClass will provide an implementation for the two instance methods using whatever means they want. This abstract specification is particularly useful to describe the desired behaviors of plug-ins for example, without constraining at all what the implementation hierarchy should be.
Static typing information may also optionally be added to variables. This information is then checked at compile time. In the following statements, increasingly specific type information is provided. The statements are equivalent at runtime, but the additional information allows the compiler to warn the programmer if the passed argument does not match the type specified. In the first statement, the object may be of any class. In the second statement, the object must conform to the aProtocol protocol, and in the third, it must be a member of the NSNumber class.
Dynamic typing can be a powerful feature. When implementing container classes using statically-typed languages without generics like pre-1.5 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. Casting however breaks the discipline of static typing – if you put in an Integer and read out a String, you get an error. One way of alleviating the problem is to resort to generic programming, but then container classes must be homogeneous in type. This need not be the case with dynamic typing.
The Objective-C runtime specifies a pair of methods in Object
and as such an object wishing to implement forwarding needs only to override the forwarding method to define the forwarding behaviour. The action methods performv:: need not be overridden as this method merely performs the method based on the selector and arguments.
$ gcc -x objective-c -Wno-import Forwarder.m Recipient.m main.m -lobjc
main.m: In function `main':
main.m:12: warning: `Forwarder' does not respond to `hello'
The compiler is reporting the point made earlier, that Forwarder does not respond to hello messages. In certain circumstances, such a warning can help us find errors, but in this circumstance, we can safely ignore this warning, since we have implemented forwarding. If we were to run the program
Recipient says hello!
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.
Furthermore, the methods within a category are added to a class at runtime. Thus, categories permit the programmer to add methods to an existing class without the need to recompile that class or even have access to its source code. For example, if the system you are supplied with does not contain a spell checker in its String implementation, you can add it without modifying the String source code.
Methods within categories become indistinguishable from the methods in a class when the program is run. A category has full access to all of the instance variables within the class, including private variables.
Categories provide an elegant solution to the fragile base class problem for methods.
If you declare a method in a category with the same method signature as an existing method in a class, the category’s method is adopted. Thus categories can not only add methods to a class, but also replace existing methods. This feature can be used to fix bugs in other classes by rewriting their methods, or to cause a global change to a class’ behavior within a program. If two categories have methods with the same method signature, it is undefined which category’s method is adopted.
Other languages have attempted to add this feature in a variety of ways. TOM took the Objective-C system a step further and allowed for the addition of variables as well. Other languages have instead used prototype oriented solutions, the most notable being Self.
gcc -x objective-c main.m Integer.m Arithmetic.m Display.m -lobjc
One can experiment by omitting the #import "Arithmetic.h" and [num1 add:num2] lines and omit Arithmetic.m in compilation. The program will still run. This means that it is possible to "mix-and-match" added categories if necessary – if one does not need to have some capability provided in a category, one can simply not compile it in.
Posing, similarly to categories, allows globally augmenting existing classes. Posing permits two features absent from categories:
This intercepts every invocation of setMainMenu to NSApplication.
However, class posing was declared deprecated with Mac OS X v10.5 and unavailable in the 64-bit runtime.
#includepre-compile directive allows for the insertion of entire files before any compilation actually begins. Objective-C adds the
#importdirective, which does the same thing, except that it knows not to insert a file which has already been inserted.
For example, if file A includes files X and Y, but X and Y each include the file Q, then Q will be inserted twice into the resultant file, causing "duplicate definition" compile errors. But if file Q is included using the
#import directive, only the first inclusion of Q will occur—all others will be ignored.
A few compilers, including GCC, support
#import for C programs too; its use is discouraged on the basis that the user of the header file has to distinguish headers which should be included only once, from headers designed to be used multiple times. It is argued that this burden should be placed on the implementor; to this end, the implementor may place the directive
#pragma once in the header file, or use the traditional
#include guard technique:
If a header file uses guards or
#pragma once, it makes no difference whether it is
#imported. The same objection to
#import actually applies to Objective-C as well, and many Objective-C programs also use guards in their headers.
Objective-C 2.0 provides an optional conservative yet generational garbage collector. When run in backwards-compatible mode, the runtime turns reference counting operations such as "retain" and "release" into no-ops. All objects are subject to garbage collection when garbage collection is enabled. Regular C pointers may be qualified with "__strong" to also trigger the underlying write-barrier compiler intercepts and thus participate in garbage collection. A zero-ing weak subsystem is also provided such that pointers marked as "__weak" are set to zero when the object (or more simply GC memory) is collected.
Objective-C 2.0 introduces a new syntax to declare instance variables as properties, with optional attributes to configure the generation of accessor methods. A property may be declared as "readonly", and may be provided with storage semantics such as "assign", "copy" or "retain".
Properties are implemented by way of the @synthesize keyword, which generates getter and setter methods according to the property declaration. Alternately, the @dynamic keyword can be used to indicate that accessor methods will be provided by other means.
Properties can be accessed using the traditional message passing syntax, dot notation, or by name via the "valueForKey:"/"setValue:forKey:" methods.
In order to use dot notation to invoke property accessors within an instance method, the "self" keyword should be used:
A class or protocol's properties may be dynamically introspected.
Fast enumeration generates more efficient code than standard enumeration because methods calls to enumerate over objects are replaced by pointer arithmetic using the NSFastEnumeration protocol.
Objective-C today is often used in tandem with a fixed library of standard objects (often known as a "kit" or "framework"), such as Cocoa or GNUstep. These libraries often come with the operating system: the GNUstep libraries often come with Linux distributions and Cocoa comes with Mac OS X. The programmer is not forced to inherit functionality from the existing base class (NSObject). Objective-C allows for the declaration of new root classes which do not inherit any existing functionality. Originally, Objective-C based programming environments typically offered an Object class as the base class from which almost all other classes inherited. With the introduction of OpenStep, NeXT created a new base class named NSObject which offered additional features over Object (an emphasis on using object references and reference counting instead of raw pointers, for example). Almost all classes in Cocoa inherit from NSObject.
Not only did the renaming serve to differentiate the new default behavior of classes within the OpenStep API, but it allowed code which used Object — the original base class used on NeXTSTEP (and, more or less, other Objective-C class libraries) — to co-exist in the same runtime with code which used NSObject (with some limitations). As well, the introduction of the two letter prefix became a sort of simplistic form of namespaces, which Objective-C lacks. Using a prefix to create an informal packaging identifier became an informal coding standard in the Objective-C community, and continues to this day.
Likewise, the language can be implemented on top of existing C compilers (in GCC, first as a preprocessor, then as a module) rather than as a new compiler. This allows Objective-C to leverage the huge existing collection of C code, libraries, tools, and mindshare. Existing C libraries — even in object code libraries — can be wrapped in Objective-C wrappers to provide an OO-style interface.
All of these practical changes lowered the barrier to entry, likely the biggest problem for the widespread acceptance of Smalltalk in the 1980s.
The first versions of Objective-C did not support garbage collection. At the time this decision was a matter of some debate, and many people considered long "dead times" (when Smalltalk did collection) to render the entire system unusable. Although some 3rd party implementations have added this feature (most notably GNUstep), Apple implemented it as of Mac OS X v10.5.
Another common criticism is that Objective-C does not have language support for namespaces. Instead programmers are forced to add prefixes to their class names, which can cause collisions. As of 2007, all Mac OS X classes and functions in 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.
Unlike C++, Objective-C does not support operator overloading. Also unlike C++, Objective-C allows an object only to directly inherit from one class (forbidding multiple inheritance). However, categories and protocols may be used as alternative functionality to multiple inheritance.
Because Objective-C uses dynamic runtime typing and because all method calls are function calls (or, in some cases, syscalls), many common performance optimizations cannot be applied to Objective-C methods (for example: inlining, constant propagation, interprocedural optimizations, and scalar replacement of aggregates). This limits the performance of Objective-C abstractions relative to similar abstractions in languages such as C++. Proponents of Objective-C claim that it should not be used for low level abstraction in the way that C++ or Java are used, because Objective-C is known to have a high runtime cost.
In addition to C’s style of procedural programming, C++ directly supports object-oriented programming, generic programming, and metaprogramming. C++ also comes with a large standard library which includes several container classes. Objective-C, on the other hand, adds only object-oriented features to C. Objective-C in its purest fashion does not contain the same number of standard library features, but in most places where Objective-C is used, it is used with an OpenStep-like library such as OPENSTEP, Cocoa, or GNUstep which provide similar functionality to some of C++’s standard library.
One notable difference is that Objective-C provides runtime support for some reflective features, whereas C++ adds only a small amount of runtime support to C. In Objective-C, an object can be queried about its own properties, for example whether it will respond to a certain message. In C++ this is not possible without the use of external libraries.
The use of reflection is part of the wider distinction between dynamic (run-time) features versus static (compile-time) features of a language. Although Objective-C and C++ each employ a mix of both features, Objective-C is decidedly geared toward run-time decisions while C++ is geared toward compile-time decisions. The tension between dynamic and static programming involves many of the classic trade-offs in computer science.