Objective-C

Related Topics:
Objective-C :: Objective_Caml

Objective-C, often referred to as ObjC or more seldom as Objective C or Obj-C, is a reflective, object oriented programming language which adds Smalltalk-style messaging to C.

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 object-oriented Objective-C programs that do not make use of these libraries can also be compiled for any system supported by gcc, which includes an Objective-C compiler.

History

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 spaghetti code 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 to run in. This virtual machine was very large and tended to require huge amounts of memory for the time and ran very slowly.

ObjC was created primarily by Brad Cox in the early 1980s at his company Stepstone. He had become interested in the problems of true reusability in software design and programming. In order to demonstrate that real progress could be made, Cox set about to show 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 that were usable, and allow for the code (and any resources needed by the code) to be bundled into a single cross-platform format.

The main description of Objective-C in its original form was published in his book, Object-Oriented Programming, An Evolutionary Approach in 1986. Cox was careful to point out that there is more to the problem of reusability than just the language, but it appears this fell on deaf ears. Instead, the system often found itself compared on a feature-for-feature basis with other languages.

Popularization through NeXT

In 1988, Steve Jobs' NeXT licensed Objective-C from StepStone and released their own Objective-C compiler and libraries on which the NeXTstep user interface and interface builder were based. The success of the tools and quality of the resultant operating system helped NeXT become a fairly popular niche workstation provider.

The GNU project started work on their free clone of NeXTStep based on the OpenStep standard, GNUstep. Dennis Glatting wrote the first gnu-objc runtime in 1992, and Richard Stallman followed with a second one shortly after. The GNU Objective-C runtime that 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 for a while.

After acquiring NeXT in 1996, Apple used OPENSTEP as the basis for its main operating system, Mac OS X. This includes 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 this is the most significant Objective-C environment being used for active development.

Syntax

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 (this cannot be said of C++). 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 message passing.

Messages

The added syntax is for built-in support of object-oriented programming. The Objective-C model of Object-oriented programming is based on sending messages to objects, similar to the model of Smalltalk. This is unlike the Simula programming model, which is used by C++ among other programming languages. This distinction is semantically important. The basic difference is that in Objective-C, one does not call a method; one sends a message.

An object called obj whose class has a method doSomething implemented is said to respond to the message doSomething. If we wish to send a doSomething message to obj, we write doSomething;

This differs from statically typed languages such as C++ and Java, in that one can send messages to objects that do not respond to them. See the dynamic typing section below.

Interfaces and implementations

Objective-C requires the interface and implementation of a class to be in separate specially declared code blocks. By convention, the interface is put in a header file and the implementation in a code file; these header files, suffixed .h, are similar to C header files.

Interface

The interface of the class is usually defined in a header file. Convention is usually to create the name of the header file based on the name of the class. So if we have the class Thing, Thing's interface goes in the file Thing.h.

The interface declaration is in this form (NOTE: the class methods need not precede the instance methods): @interface classname : superclass name { instance variables } + class method + class method ... - instance method - instance method ... @end

Implementation

The interface only declares the prototypes for the methods, and not the methods themselves, which go in the implementation. The implementation is usually stored in a main file, for example, Thing.m. The implementation is written

@implementation classname + class method { implementation } - instance method { implementation } ... @end

Methods are written in a different way from C-style functions. For example, a function in both C and Objective-C follows this general form: int do_something(int i) { return square_root(i); }

with int do_something(int) as the prototype.

When this is implemented as a method, this becomes: - (int) do_something: (int) i { return square_root: i; }

However, a more canonical way of writing this method would be like this, by naming the first argument in the selector name: - (int) doSomethingWithInt: (int) i { return squareRootOfInt:i; }

The hyphen lets us know that this is an instance method, and not a class method (which uses a +). This syntax may appear to be more troublesome but it allows the naming of parameters, for example

- (int) changeColorWithRed: (int) r green: (int) g blue: (int) b ...

which can be invoked thus:

changeColorWithRed:5 green:2 blue:6;

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.

However, internal names of the function are rarely used directly, and generally even message-sends are converted to a call to a function defined in a run-time library rather than directly accessing the internal name. This is partially because it is rarely known at compile-time which method will actually be called, because the class of the receiver (i.e. the object being sent the message) is rarely known until runtime.

Protocols

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 as an abstract multiply inherited base class in C++ or, more popularly adopted in Java 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 that 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 that 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. It is a list of methods that any class can declare itself to implement. The compiler will emit an error if the class does not implement every method of its declared protocols. The Objective-C concept of protocols is different from the Java 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. Unlike Java's interfaces, formal protocols cannot provide any implementations, they simply assure callers that classes that 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

@protocol Locking - (void)lock; - (void)unlock; @end

denotes that there is the abstract idea of locking that is useful and when stated in a class definition

@interface SomeClass : SomeSuperClass ... @end

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.

Dynamic typing

Objective-C, like Smalltalk, can use Dynamic typing; we can send an object a message not specified in its interface. Although controversial, this can allow for increased flexibility — in Objective-C an object can "capture" this message, and depending on the object, can send the message off again to a different object (who can respond to the message correctly and appropriately, or likewise send the message on again). This behaviour is known as message forwarding or delegation (see below). Alternatively, an error handler can be used instead, in case the message cannot be forwarded. However if the object does not forward the message, handle the error, or respond to it, a runtime error occurs.

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 must conform to the aProtocol protocol, and in the second, it must be a member of the NSNumber class.

- setMyValue: (id ) foo; - setMyValue: (NSNumber*)foo; 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 needs not be the case with dynamic typing.

Forwarding

As mentioned, since Objective-C permits the sending of a message to an object that might not respond to it, the object has a number of things it can do with the message. One of these things could be to forward the message on to an object that can respond to it. Forwarding can be used to implement certain design patterns, such as the Observer pattern or the Proxy pattern very simply. See Examples of message forwarding in Objective-C for such an implementation.

The Objective-C runtime specifies a pair of methods in Object

forwarding methods:

- (retval_t) forward: (SEL) sel : (arglist_t) args; // with GCC - (id) forward: (SEL) sel : (marg_list) args; // with NeXT/Apple systems

action methods:

- (retval_t) performv: (SEL) sel : (arglist_t) args; // with GCC - (id) performv: (SEL) sel : (marg_list) args; // with NeXT/Apple systems 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.

Example

Here is an example of a program that demonstrates the basics of forwarding.

Forwarder.h

#import @interface Forwarder : Object { id recipient; //The object we want to forward the message to. } //Accessor methods - (id) recipient: (id) _recipient; - (id) recipient; @end

Forwarder.m

#import "Forwarder.h" @implementation Forwarder - (retval_t) forward: (SEL) sel : (arglist_t) args { /* * Check whether the recipient actually responds to the message. * This may or may not be desirable, for example, if a recipient * in turn does not respond to the message, it might do forwarding * itself. */ if(respondsTo:sel) return performv: sel : args; else return error:"Recipient does not respond"; } - (id) recipient: (id) _recipient { recipient = _recipient; return self; } - (id) recipient { return recipient; } @end

Recipient.h

#import // A simple Recipient object. @interface Recipient : Object - (id) hello; @end

Recipient.m

#import "Recipient.h" @implementation Recipient - (id) hello { printf("Recipient says hello!\n"); return self; } @end

main.c

#import "Forwarder.h" #import "Recipient.h" int main(void) { Forwarder *forwarder = new; Recipient *recipient = new; recipient:recipient; //Set the recipient. /* * Observe forwarder does not respond to a hello message! It will * be forwarded. All unrecognized methods will be forwarded to * the recipient * (if the recipient responds to them, as written in the Forwarder) */ hello; return 0; }

Notes

If we were to compile the program, the compiler would report that $ gcc -x objective-c -Wno-import Forwarder.m Recipient.m main.c -lobjc main.c: In function `main': main.c:12: warning: `Forwarder' does not respond to `hello' $

The compiler is reporting the point that was made earlier, Forwarder does not respond to hello messages. In certain circumstances, such a warning can help us find errors, but in this circumstance however, we can safely ignore this warning, since we have implemented forwarding. If we were to run the program $ ./a.out Recipient says hello!

For more examples, see examples of message forwarding in Objective-C

Posing

Objective-C permits a class to wholly replace another class within a program. The replacing class is said to "pose as" the target class. All messages sent to the target class are then instead received by the posing class. There are several restrictions on which classes can pose:

A class may only pose as one of its direct or indirect superclasses
The posing class must not define any new instance variables that are absent from the target class (though it may define or override methods).
No messages must have been sent to the target class prior to the posing.

Posing, similarly to categories, allows globally augmenting existing classes. Posing permits two features absent from categories:

A posing class can call overridden methods through super, thus incorporating the implementation of the target class.
A posing class can override methods defined in categories.

For example,

@interface CustomNSApplication : NSApplication @end @implementation CustomNSApplication - (void) setMainMenu: (NSMenu*) menu { // do something with menu } @end class_poseAs (class, class);

This intercepts every invocation of setMainMenu to NSApplication.

#import

In the C language, the "#include" pre-compile directive allows for the insertion of entire files before any compilation actually begins. ObjC adds the "#import" directive, which does the same thing, except that it knows not to insert a file that 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.

Other features

Objective-C in fact included a laundry-list of features that are still being added to other languages, and some that are unique to it. 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.
Pointer 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.

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 a combination of C++ and Objective-C syntax. Objective-C++ adds to C++ the extensions Objective-C adds to C. As nothing is done to unify the semantics behind the various language features, certain restrictions apply:

A C++ class cannot derive from an Objective-C class and vice versa.
C++ namespaces cannot be declared inside an Objective-C declaration.
Objective-C classes cannot have instance variables of a C++ class type that has virtual functions, but pointers to C++ objects can be declared.
C++ "by value" semantics cannot be applied to Objective-C objects, which are only accessible through references.
An Objective-C declaration cannot be within a C++ template declaration and vice versa. Objective-C types, (e.g., Classname *) can be used as C++ template parameters, however.

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, which adds some additional features to Object, such as reference counting.

History note: Earlier versions of NeXT's NeXTSTEP operating system had objects inheriting from Object, but migrated to the newer NSObject root class, which was named to distinguish it from the original Object root (see note on namespaces below). All newer versions of the NeXTSTEP libraries which had objects inheriting from NSObject were prefixed with "NS", while 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. On the other hand, Cocoa has a class which does not inherit from NSObject: NSProxy.

Analysis of the language

Objective-C is a very pragmatic language. Objective-C implementations use a thin runtime written in C that adds little to the size of the application. In contrast, most OO systems at the time that it was created used large VM runtimes that took over the entire system. Programs written in Objective-C tend to be not much larger than the size of their code and that of the libraries (which generally don't need to be included in the software distribution), in contrast to Smalltalk systems where a large amount of memory was used just to open a window.

Likewise, the language can be implemented on top of existing C compilers (in the GCC, first as a preprocessor, then as a module) rather than as a new compiler. This allowed 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. Objective-C can thus be described 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 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 has not implemented it as of Mac OS X v10.4, but is planning to do so in the near future.

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 2004, 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, though it does support overloading. Also unlike C++, Objective-C allows an object only to directly inherit from one class (forbidding multiple inheritance). As Java was influenced by the design of Objective-C, the decision to use single inheritance was carried into Java. Categories and protocols may be used as alternative functionality to multiple inheritance; Java however lacks categories.

Philosophical differences between Objective-C and C++

The design and implementation of C++ and Objective-C represent different approaches to extending C.

C++ provides templates to support generic programming and metaprogramming, and a standard library with container classes. C++ requires this because C++ is a statically-typed language. Objective-C adds only object oriented features — Objective-C does not need to have template programming because it supports dynamic typing. Objective-C in its purest fashion does not contain the same number of standard library features, however in most places where Objective-C is used, it is used with an OpenStep-like library such as OPENSTEP, Cocoa, or GNUstep, providing the same functionality as C++'s standard library.

At run time, most information about types in C++ is gone, and there is no standard way to, for instance, call a certain method given only its name. In contrast, as Objective-C is dynamically typed, type information remains directly available at run time. For instance, one can call an Objective-C method given only a string representing its name.

External links

History

Popularization through NeXT

Syntax

Messages

Interfaces and implementations

Interface

Implementation

Protocols

Dynamic typing

Forwarding

Example

Notes

Categories

Example usage of categories

= Notes

Posing

#import

Other features

Objective-C++

Today

Analysis of the language

Philosophical differences between Objective-C and C++

See also

External links

Gourt Home::Gourt :: Objective-C

History

Popularization through NeXT

Syntax

Messages

Interfaces and implementations

Interface

Implementation

Protocols

Dynamic typing

Forwarding

Example

Notes

Categories

Example usage of categories

= Notes

Posing

#import

Other features

Objective-C++

Today

Analysis of the language

Philosophical differences between Objective-C and C++

See also

External links