The Run-Time System

The Objective-C language defers as many decisions as it can from compile time and link time to run time. Whenever possible, it does things dynamically. This means that the language requires not just a compiler, but also a run-time system to execute the compiled code. The run-time system acts as a kind of operating system for the Objective-C language; it's what makes the language work.

Objective-C programs interact with the run-time system at three distinct levels:

• Through Objective-C source code. For the most part, the run-time system works automatically and behind the scenes. You use it just by writing and compiling Objective-C source code.
  
  It's up to the compiler to produce the data structures that the run-time system requires and to arrange the run-time function calls that carry out language instructions. The data structures capture information found in class and category definitions and in protocol declarations; they include the class and protocol objects discussed earlier, as well as method selectors, instance variable templates, and other information distilled from source code. The principal run-time function is the one that sends messages, as described under "How Messaging Works" in "The Objective-C Language" . It's invoked by source-code message expressions.
• Through a method interface defined in the NSObject class. Every object inherits from the NSObject class, so every object has access to the methods it defines. Most NSObject methods interact with the run-time system.
  
  Some of these methods simply query the system for information. The preceding chapters, for example, mentioned the class method, which asks an object to identify its class; isKindOfClass: and isMemberOfClass:, which test an object's position in the inheritance hierarchy; respondsToSelector:, which checks whether an object can accept a particular message; conformsToProtocol:, which checks whether it conforms to a protocol; and methodForSelector:, which asks for the address of a method implementation. Methods like these give an object the ability to introspect about itself.
  
  Other methods set the run-time system in motion. For example, performSelector: and its companion initiate messages, and alloc produce a new object properly connected to its class.
  
  All these methods were mentioned in previous chapters and are described in detail in the NSObject class specification in the Foundation Framework reference.
• Through direct calls to run-time functions. The run-time system has a public interface, consisting mainly of a set of functions. Many are functions that duplicate what you get automatically by writing Objective-C code or what the NSObject class provides with a method interface. Others manipulate low-level run-time processes and data structures. These functions make it possible to develop other interfaces to the run-time system and produce tools that augment the development environment; they're not needed when programming in Objective-C.
  
  However, a few of the run-time functions might on occasion be useful when writing an Objective-C program. These functions-such as sel_getUid(), which returns a method selector for a method name, and objc_msgSend(), which sends a message to an object-are defined in the Objective-C run time system described at various places in the text of this book.

Because the NSObject class is at the root of all inheritance hierarchies, the methods it defines are inherited by all classes. Its methods therefore establish behaviors that are inherent to every instance and every class object. However, in a few cases, the NSObject class merely defines a framework for how something should be done; it doesn't provide all the necessary code itself.

For example, the NSObject class defines a description method that should return an NSString associated with the receiver. If you define a class of named objects, you can implement a description method to return the specific character string associated with the receiver. NSObject's version of the method can't know what that name will be, so it merely returns the class name as a default.

This chapter looks at three areas where the NSObject class provides a framework and defines conventions, but where you may need to write code to fill in the details:

• Allocating and initializing new instances of a class, and deallocating instances when they're no longer needed
• Forwarding messages to another object
• Dynamically loading new modules into a running program

Other conventions of the NSObject class are described in the NSObject class specification in the Foundation Framework reference.

© 2001 Apple Computer, Inc.