1.3 Elements of the Language

Objective-C extends the C language with the following concepts and constructs:

• Objects (instances of classes)

• Classes

• Inheritance and subtyping

• Fields

• Methods and method calls (or messages)

• Categories

• Protocols

• Declarations (extended from C to include class and protocol types)

• Predefined types, constants, and variables

• Compiler and preprocessor directives

The following sections will describe these aspects of Objective-C.

1.3.1 Objects

Objects are the compound values—data and operations—at the heart of object-oriented programming. They are generalizations of simple structured types found in C and many other languages. Like C structs, objects have components—data fields—that maintain state. For example, a Book object might have fields to specify the author and publisher. In addition, objects interact through message passing, which provides an alternative to the function calls of a procedural language.

Objective-C objects have these attributes:

Class

An object type. An object whose type is MyClass is said to be an instance of MyClass.

Fields

Data members of an object. An object has its own copies of the fields declared by its class or its ancestor classes.

Fields are also referred to as "instance variables." I prefer the term "fields" for several reasons: "instance variables" is redundant since there are no class variables, it is ambiguous since it could mean variables that are instances, just "variables" would be more ambiguous, and "fields" is shorter. (An alternative term is "ivars.")

Methods

Functions provided by an object. An object responds to methods declared by its class or ancestor classes.

A few special objects (class objects) acquire their fields and methods differently. Section 1.9 describes class objects.

Objective-C objects are implemented so that:

• They exist in dynamically allocated memory.

• They can't be declared on the stack or passed by value to other scopes.

• They are referred to only by pointers.

When someone says of an Objective-C variable: "c is an instance of C", you should understand that to mean that c is a pointer to an object of type C.

1.3.2 Classes

Classes are types in Objective-C. The interface of a class specifies the structure of its instances; the implementation provides its code. The interface and implementation of a class are separate, usually in different files. Categories add to an existing class without subclassing it; they also have separate interface and implementation. Protocols are pure interface declarations.

Classes declare the following attributes:

Parent class

The class whose methods and fields will be inherited by the new class being declared.

Class name

The name of the class being declared.

Fields

Data members of each instance of the class.

Instance methods

Functions associated with instances of the class.

Class methods

Functions associated with the class itself.

Because Objective-C makes calling class methods syntactically identical to calling instance methods, classes themselves behave much like objects. Section 1.9 discusses class objects.

1.3.2.1 Declaring an interface

An interface names a class and declares its parent (if any), fields, and methods, without specifying any implementation. (You can't use C++-style inline methods, implemented in the header.) A header file can contain any number of interface declarations, but it is conventional to put each interface in a separate header file. By default, gcc expects the filename to end in .h.

Following is an example interface declaration. (Note that the line numbers are not part of the source code.)

 1 #import  "Graphic.h "
 2
 3 @class  Point ;
 4
 5 @interface  Circle  : Graphic  {
 6   @protected   // or @public or @private
 7     float   radius ; 
  8     Point * center ;
 9 }
10   -(void )scaleBy :(float )factor ;
11   +(void )numCircles ;
12 @end 

Line 1. The #import directive is like C's #include directive, except that the compiler ensures that no file is included more than once. You always need to import the declaration of your class's parent class (if any). You don't need to import any other Objective-C class declarations, but it may be convenient to import some umbrella header files as a matter of routine.

Line 3. You use the ec@class declaration when your class's fields, or the return values or parameters of your class's methods, are instances of another class. You can use separate @class declarations for distinct classes, or use a single declaration with the class names separated by commas.

A class declaration doesn't need any more information about any other class, so you don't need to import a header unless the header has other declarations (e.g., macros or globals) that your class declaration needs.

Line 5. Specify the name of your class and that of the parent class (if any). The name of your class will be visible to any code that includes the header file. All class names exist in the global namespace, along with global variable names and type names.

Line 6. Access keywords control compile-time checking of access to fields. You can repeat these as often as you want; a field has the access permission specified by the most recent preceding keyword. If there is no preceding keyword, access permission defaults to protected.

In brief, public fields are visible to all subclasses and all external code, protected fields are visible only to subclasses, and private fields are visible only in the class being declared. Section 1.3.4 gives exact rules.

Line 7. Declare fields in the same manner as you declare structure members in C. Fields can be of any C type, as well as of any class or other type (described in Section 1.3.9) added by Objective-C. Fields can have the same name as methods in the same class.

Fields are not shared between instances—that is, Objective-C does not support class variables. But you can get the same effect by declaring ordinary variables as static in the implementation file. (See the following Section 1.3.2.2 for an example.)

Line 8. You incorporate other objects only by pointer, not by value. Objective-C's predefined id, Class, and Protocol types are pointer types already.

Line 9. No semicolon after the closing brace.

Line 10. An instance method is marked with a - character. Instance methods operate on instances of the class. Method signatures use Objective-C's infix syntax, discussed later in Section 1.3.5.

You don't need to redeclare a method if you are inheriting it. It is conventional to redeclare a method if your class inherits and overrides it. Section 1.3.5.4 explains why you should declare a method in all other cases. (But not necessarily in the header file; see Section 1.3.5.5.) Methods can have the same name as fields of the same class, and instance methods can share names with class methods.

Line 11. A class method is marked with a + character. Class methods perform operations or return information about the class as a whole, and don't pertain to any instance of the class.

Line 12. No semicolon after the @end keyword.

1.3.2.2 Implementing a class

You implement a class by writing the code (i.e., the bodies) for each of the class's methods. A file can contain any number of class implementations, but it is conventional to put each implementation in a separate file. By default, gcc expects the filename to end in .m (for Objective-C) or .mm or .M (for Objective-C++). Even if a class has no methods, it must have an empty implementation.

If you don't provide a class implementation, the compiler will not emit support code for the class, and the linker will fail.

Here is a simple implementation for the class declared in the previous section:

1 #import  "Circle.h "
2
3 static  int  count ;
4
5 @implementation  Circle 
6   // No field section.
7   +(void )numCircles  { return  count ; }
8   -(void )scaleBy :(float )factor  { radius  *= factor ;}
9 @end 

Line 1. Always import the header file that declares your class. If your code uses other classes (e.g., it sends messages to them or their instances) you need to import the headers of those classes too. There is little point to using an @class declaration here—if you use another class in an implementation you will need its interface declaration.

Line 3. This is a pure C declaration, reserving space for a per-class variable. (In this example, it would be used to keep count of the number of objects created. That code is not shown.) It will be visible only in this implementation file.

Line 5. Specify the name of the class you are implementing.

Line 6. You can't add any more fields here, so there is no brace-delimited section corresponding to the one in the interface declaration.

Lines 7, 8. Define methods with the same signature syntax as in the header; follow each method definition with the code, in braces. For more information on writing the code, see Section 1.3.5.

Line 9. No semicolon after the @end keyword.

1.3.3 Inheritance and Subtyping

Inheritance and subtyping are the fundamental object-oriented features: inheritance lets you declare how one type differs from another, and subtyping lets you substitute one kind of object for another when their types are compatible.

A class's interface may declare that it is based on another class:

@interface  MyClass  : Parent 

This is described by saying MyClass is a subclass of Parent, and has the following runtime effects:

• MyClass responds to any class method that Parent responds to.

• Instances of MyClass have all the fields that instances of Parent have.

• Instances of MyClass respond to any instance methods that instances of Parent respond to.

These effects are summarized by saying MyClass inherits Parent's fields and methods. These properties imply that inheritance is transitive: any subclass of MyClass also inherits from Parent.

Declaring a class and specifying a parent also has these effects at compile time:

• You can refer to inherited methods and fields.

• You can assign variables declared as MyClass to variables declared as Parent.

This is described by saying MyClass is a subtype of Parent. Subtyping is also transitive. For example, any subclass of MyClass is a subtype of Parent.

You can't redeclare fields in a subclass, either identically or with a different type. (Unlike C++, this holds even if the inherited field was declared private.)

A subclass can replace, or override , an inherited method with a different version. You do this by providing a new implementation for the method when you write the subclass. At runtime, instances of the subclass will execute the new code in the overriding method instead of the code of the inherited method. By definition, the overriding method has the same name as the inherited one; it must also have the same return and parameter types. (You can't overload methods as in C++.) You don't need to redeclare the overriding method, but it is conventional to do so.

1.3.4 Fields

Fields are data members of objects. Each object gets its own copy of the fields it inherits or declares.

Inside the methods of a class you can refer directly to fields of self, either declared in the class or (if they are not private) inherited:

@interface  Circle  : Graphic  {
  float  radius ;   // Protected field.
  // etc.
@end 
    
@implementation  Circle 
  -(float )diameter  {
    return  2 * radius ; // No need to say self->radius.
  }
@end 

If an object other than self is statically typed, you can refer to its public fields with the dereference operator:

AClass* obj;      // Static typing required.
obj->aField = 7;  // Presuming aField is public.

1.3.4.1 Access modifiers

Access to an object's field depends on four things:

• The field's access permission (public, private, or protected)

• The class of the accessing code

• The class of the object

• The nature of the object: whether it is the receiver (self) or another variable (global, local, or method parameter)

There is no notion of read-only members in Objective-C: if you can read a field, you can also write to it.

You declare a field's access permission in its class's interface. Any of three access keywords—@public , @protected, and @private—may appear any number of times in an interface declaration and affects all fields declared after it until the next access keyword. (See the example in Section 1.3.2.) If there is no preceding keyword, a field has protected access.

Following are the keywords and their effects on access to an object's fields:

@public

A public field is visible to all code.

@protected

If the object is self, a protected field is visible.

If the object is not self, access depends on its class:

• If the object's class is the same as that of the receiver, the field is visible.

• If the object inherits from the receiver's class, the field is not visible. (You can get around this by casting the object to the receiver's class.)

• If the object has any other relation to the receiver's class, the field is not visible.

@private

If the object is self, a private field is visible.

If the object is not self:

• If the object's class is the same as that of the receiver, the field is visible.

• In all other cases, the field is not visible.

1.3.5 Methods

Methods are the functions associated with an object, and are used as interfaces for querying or changing the object's state, or for requesting it to perform some action.

Objective-C uses the terms "calling a method" and "sending a message" interchangeably. This is because method dispatch is less like dereferencing a function pointer and more like searching for a recipient and delivering a message. Most of the work of method lookup is done at runtime.

You send messages to objects using Objective-C's bracket syntax. Method names are associated with parameters using an infix syntax borrowed from Smalltalk. Objective-C provides directives for accessing the runtime dispatch mechanism directly.

1.3.5.1 Declaring a method

You declare a method in an interface or protocol by specifying who handles it (either the class or an instance of the class), its return type, its name, and its parameter types (if any). The name is broken up so that part of it precedes each parameter. The form of a declaration depends on the number of parameters, as described in the following sections.

1.3.5.1.1 No parameters

-(id)init;

This declaration can be broken down as follows:

-

Indicates an instance method; use a + for class methods.

(id)

Indicates that the return type is id. Specifying a return type is optional; the default return type is id.

init

The method's name.

1.3.5.1.2 One parameter

+(void )setVersion:(int )v ;

This declaration can be broken down as follows:

+

Indicates a class method.

(void)

Indicates that the return type is void.

setVersion:

The method name. This method name includes a colon, which indicates a parameter to follow.

(int)

Specifies that the parameter is an int. If you omit the parameter type, it defaults to id.

v

The parameter name. You need the name in both declaration and implementation, although it's only used in the implementation.

1.3.5.1.3 More than one parameter

-(id )perform:(SEL )sel  with:(id )obj ;

This declaration can be broken down as follows:

-

Indicates an instance method.

(id)

Indicates that the return type is id.

perform:

The first part of the method name. This method name has two parts, one preceding each of the parameters. The full method name is perform:with:. Methods with more parameters follow the same pattern as shown here. The second, third, etc. parts of a method name don't need any textual characters, but the colons are required.

(SEL)

Specifies that the first parameter has the type SEL.

sel

The name of the first parameter.

with:

The second part of the method name.

(id)

Specifies that the second parameter has the type id.

obj

The name of the second parameter.

1.3.5.1.4 A variable number of parameters

-(id )error:(char *)format ,...;

This declaration can be broken down as follows:

-

Indicates an instance method.

(id)

Indicates that the return type is id.

error:

The entire method name. In this case, the second and subsequent parameters are not prefaced by extensions of the method name.

(char*)

Specifies the type of the first parameter.

format

The name of the first parameter.

...

Represents the variable-size parameter list. Ellipses like these can only appear at the end of a method declaration. In the method, access the list using the standard C variable-arguments interface.

1.3.5.2 Implementing a method

The body of a method appears in the implementation section of a class. The method starts with a declaration, identical to that of the interface section, and is followed by code surrounded by braces. For example:

-(void )scaleBy :(float )factor  {
  radius  *= factor ;
}

Inside a method body, refer to fields the class declares or inherits with no qualification. Refer to fields of other objects using the dereference (->) operator.

Objective-C defines three special variables inside each method:

self

The receiver of the method call.

super

A reference to the inherited version of the method, if there is one.

_cmd

The selector—an integer that uniquely specifies the method.

Section 1.3.9 describes these special variables in more detail.

1.3.5.3 Calling a method

Every method call has a receiver—the object whose method you are calling—and a method name. You enclose a method call in brackets [ ] with the receiver first and the method name following. If the method takes parameters, they follow the corresponding colons in the components of the method name. Separate receiver and name components by spaces. For example:

[aCircle initWithCenter:aPoint andRadius:42];

If a method takes a variable number of parameters, separate them with commas:

[self  error:"Expected %d but got %d ", i , j ];

A method call is an expression, so if the method returns a value you can assign it to a variable:

int  theArea  = [aCircle  area ];

Method calls can be nested:

Circle* c1 = ... // whatever
Circle* c2 = 
  [[Circle alloc] initWithCenter:[c1 center]
                  andRadius:[c1 radius]];

1.3.5.4 Naming collisions

When the compiler encodes a method call, it needs to set up, then and there, room for the parameters and return value (if any). This is a nondynamic aspect of method calls. To encode the call properly, the compiler must know the parameter and return types.

If you leave the type of a receiver unknown (that is, declared as id) until runtime, the name of a method may be all the information the compiler has when it compiles the method call. The compiler will encode the method call based on previous uses of the same method:

• If the compiler has not yet seen any methods with the name used, it will assume the return type and parameters are all id (a pointer whose size is platform-dependent) and will issue a warning message. If you use variables of type other than id, the compiler will convert them according to standard C rules and they may not survive intact.

• If the compiler has seen exactly one method with the same name, it will emit code assuming the return and parameter types match those it saw.

• If the compiler has seen more than one method with the same name, and differing return or parameter types, it will not know how to encode the method call. It will choose one option and issue a warning message. As in the first case, type conversions may play havoc with your data values.

The compiler will not let you declare, in related classes, methods with the same name but different parameter types (no C++-style overloading), but you can do this in unrelated classes. To avoid forcing the compiler to guess your intentions, methods with the same name, even in different classes, should usually have the same signature.

You can relax this restriction if you know the receiver of the call will always be statically typed. But you may not have control over all future use of your method.

1.3.5.5 Private methods

Because the compiler needs to know parameter types to generate method calls, you should also not omit method declarations in an attempt to make them private. A better way to make a method private is to move the method declaration to its class's implementation file, where it will be visible to the code that uses it but not to any other part of your program.

The following example shows how to use a category (described at greater length in Section 1.3.6) to declare a method in an implementation file:

1 @interface  Circle  (PrivateMethods )
2   -(float )top ;
3 @end 
4
5 @implementation  Circle 
6   // Public definitions as before.
7   ...
8   // Now implement the private methods.
9   -(float )top  { return  [center  y ] - radius ; }
8 @end 

Line 1. At the beginning of your class's implementation file, declare a category that extends the class.

Line 2. Methods declared here are just as much part of the class as the ones declared in the regular interface, but will be visible only in this file.

Line 5. Your class's implementation, in the usual fashion.

Line 6. Implement the methods declared in the header file. They can call the private methods (as well as other public methods, of course).

Line 8. Implement the private methods. They can call public and private methods.

1.3.5.6 Accessors

Accessors are methods for setting and returning an object's fields. Objective-C has several conventions for writing accessors:

• To return a variable, provide a method with the same name as the variable. You can do this because methods and fields have separate namespaces.

• To set a variable, provide a method with the same name as the variable that takes the new value as a parameter. For example, given a variable named radius, use radius:(float)r as the signature for your setter method. You can do this because the colon preceding the parameter is part of the methods' name, so radius: the setter will be differently named from the radius the getter.

Here is an example of how to write accessors for a simple field:

@implementation  Circle 
  -(float )radius  { return  radius ; }
  -(void )radius :(float )r  { radius  = r ; }
@end 

Don't use "get" in the name of your accessors. By convention, methods whose names start with "get" take an address into which data will be copied.

If you are using reference counting, there are more design patterns you should follow when writing accessors. These are discussed in Section 1.12.2.

1.3.5.7 Message search paths

When you send an object a message (call one of its methods), the code that actually runs is determined by a search performed at runtime.

The dispatch of the method call proceeds as follows:

Section 1.9 provides more details about method dispatch.

1.3.5.8 Special receivers

The receiver is the object to which you are sending a message. Its instance methods will be given the first chance to handle the call, followed by the instance methods of its ancestor classes.

Besides the typical case of sending a message to a named receiver, there are several special targets:

self

Refers to the object that is executing the current method. At runtime, the class of self may be the class in which the call to self appears, or it may be a subclass.

super

Refers to the inherited version of the method.

When you use the predefined variable super as the receiver, you are sending a message to self but instructing the runtime to start method lookup in the parent class of the class in which the send occurs.

This is not the same as starting in the parent class of the receiver—the class of super is determined at compile time. If this were done dynamically, the following code would cause an infinite loop:

1 @implementation  C 
2   -(void ) f  { [super  f ]; }
3 @end 
4
5 // And elsewhere:
6 D * d  = [D  new];
7 // D inherits from C, does not override f.
8 [d  f ];  // Executes in C's version.

Here, D is a subclass of C that does not override f. The call at line 8 would dispatch to line 2, but the call to super would be redirected to the parent class (C) of the receiver (D)—i.e., back to line 2.

Any class name

Refers to the class object that represents the named class. When you call a class method you are actually sending a message to a class object. (See Section 1.9.) If you don't have the class object on hand, this syntax lets you use the class's name as the receiver.

nil

It is not an error to send a message to nil (an uninitialized or cleared object). If the message has no return value (void), nothing will happen. If the message returns an object pointer, it will return nil. If the message returns a scalar value such as an int or float, it will return zero. If the message returns a struct, union, or other compound value, its return value is not specified and you should not depend on it. This behavior makes it easier to chain together method calls. For example:

id  widget  = [[[window  child ] toolbar ] widget ];

If sending a message to nil caused a runtime error, you would have to check the result of each message. This property of nil should not tempt you to be lax with your runtime checking, but it may suffice to test only the end result of a chain of method calls.

1.3.5.9 Selectors

Objective-C methods are distinguished by their names, which are the concatenation of the component parts of the method name, including the colon characters. At compile time, each name is matched to a unique integer called the selector. The Objective-C type SEL represents a selector's type.

When a method call is compiled, it is distilled to its receiver, selector, and parameters. At runtime, the message is dispatched by matching the selector with a list maintained by the receiver's class object.

You can use selectors to make a runtime decision about what method to call—the Objective-C version of function or method pointers.

1 SEL  mySel  = @selector (center );
2 Point * p  = [aCircle  perform:mySel ];

Line 1. The compiler knows the mapping from selector names to SELs and will emit code assigning to mySel the value corresponding to the method name center.

Line 2. Using the selector, you can instruct the receiver to respond to the message as if it had been sent in the usual way. The effect is the same as executing the direct method call:

Point* p = [aCircle center];

Section 1.10 gives more information about the -perform: methods.

1.3.6 Categories

Objective-C provides the category construct for modifying an existing class "in place." This differs from writing a new subclass: with inheritance you can only create a new leaf in the inheritance tree; categories let you modify interior nodes in the tree.

With a category, the full declaration of a class can be spread out over multiple files and compiled at different times. This has several advantages:

• You can partition a class into groups of related methods and keep the groups separate.

• Different programmers can more easily work on different parts of the class.

• For diverse applications, you can provide only those parts of the class that are needed. This gives you finer-grained control over expressing dependencies without having to provide different versions of the class.

• You can add methods to classes from the operating system's library or from third-party sources without having to subclass them.

1.3.6.1 Declaring a category

Here is an example of declaring a category to add methods to the Circle class:

1 #import  "Circle.h "
2
3 @interface  Circle  (Motion )
4   // No field section.
5   -(void )moveRight :(float )dx ;
6   -(void )moveUp :(float )dy ;
7 @end 

Line 1. The declaration can be in the same header file as the declaration of the class it modifies, or in a separate file. If it is in a separate header file, you may need to include the header file of the modified class.

Line 3. Declare the name of the class you are modifying and the name of your category. In this example, Circle is the class name, and Motion is the category name. Category names have their own namespace, so a category can have the same name as a class or a protocol.

Line 4. There is no fields section in the category declaration, so you can't use a category to add fields to a class.

Lines 5, 6. Declare methods here as in a class interface.

Line 7. No semicolon after the @end keyword.

You can declare a category in a header or an implementation file. If the declaration is in a header file, its methods are full members of the modified class. Any code can use the new methods with the modified class (and its subclasses). If the declaration is in an implementation file, only code in that file can use the new methods, and their implementation must appear in that file. This is a way of making methods private.

If you declare in your category a method with the same name as one in the modified class, the new method overrides the old one. When such an overriding method sends messages to super, they go to the same method in the parent class (just as they would in the overridden version) and not to the overridden method itself. You can't send messages to the overridden version. You should simply avoid using categories to override methods.

If several categories that modify the same class all declare a method with the same name, the results are implementation dependent. In other words, don't do this. The gcc compiler does not warn you about this.

You don't have to implement all or even any of the methods you declare in a category. The compiler will warn you if you have an implementation section for your category and omit any methods. If you have no implementation at all for a category, this is called declaring an informal protocol. Section 1.3.7 discusses these further.

1.3.6.2 Implementing a category

You implement the methods of the category in an implementation file, like this:

1 #import  "Motion.h "
2
3 @implementation  Circle  (Motion )
4   -(void )moveRight :(float )dx  { ... }
5   -(void )moveUp :(float )dy  { ... }
5 @end 

Line 1. You need to include the declaration of the category you are implementing. If the declaration is in the same file as the implementation, you don't need this line.

Line 3. Specify the name of the modified class and the name of your category.

Line 4. Methods take the same form and have the same access to fields as in a regular class implementation.

Line 5. No semicolon after the @end keyword.

1.3.7 Protocols

Protocols are lists of method declarations that are not associated with a specific class declaration. Protocols let you express that unrelated classes share a common set of method declarations. (This facility inspired Java's interface construct.) Protocols let you do the following:

• Use static type checking where you want it

• Specify interfaces to other code

• Factor common features of your class hierarchy

Objective-C declarations can specify that an instance must support a protocol, instead of (or in addition to) conforming to a class. (See Section 1.3.8.)

1.3.7.1 Declaring a protocol

You declare a protocol in a header file like this:

1 @protocol  AnotherProtocol ;
2
3 @protocol  Printable  <Drawable >
4   -(void )print ;
5 @end 

Line 1. You need the forward protocol declaration if return or parameter types of methods in your protocol use the other protocol.

Protocol names have their own namespace, so a protocol can have the same name as a class or a category.

Line 3. If your protocol extends other protocols, name those in the protocol list. The list is a sequence of protocol names, separated by commas. If the list is empty, you can omit the angle brackets. You don't need to redeclare the methods of the listed protocols. When a class adopts the protocol you are declaring, it must implement all the methods declared in your protocol and all the other protocols in the list. (You can't write partially abstract classes as in C++, with some methods declared but not implemented.)

Line 4. You declare your methods here in the same form as in a class interface.

Line 5. No semicolon after the @end keyword.

1.3.7.2 Adopting a protocol

When you want your class to adopt (implement) one or more protocols, you declare it like this:

#import  "Printable.h "
@interface  Circle  : Graphic  <Printable >

When you want your category to adopt a protocol you declare it like this:

#import  "Printable.h "
@interface  Circle  (Motion ) <Printable >

The list of protocols, inside the angle brackets, consists of names separated by commas. You have to import the header files where the protocols are declared. Don't redeclare the protocol's methods in your interface; just define them in your implementation. You have to define all the methods of the protocol.

When you declare a field or variable, you can specify that it represents an instance whose class conforms to a specific protocol like this:

id  <Printable > obj ;
ClassName  <Printable >* obj ;

For more about this, see Section 1.3.8.

1.3.7.3 Checking for conformity to a protocol

At runtime, you can check if an object's class conforms to a protocol by using the -conformsTo: (from the root class Object) or +conformsToProtocol: (from NSObject) methods:

[obj  conformsTo:@protocol (Printable )];

Like classes, protocols have special runtime structures associated with them called protocol objects. Section 1.9 describes these.

1.3.7.4 Informal protocols

You can get some of the functionality of a protocol by declaring but not implementing a category. Such a category is called an informal protocol . You can't declare that a class does or does not implement an informal protocol, so you can't use it for static type checking. You can use an informal protocol to specify a group of methods that all subclasses of the modified class may implement, but are not obliged to implement. This serves as something less than a full protocol but more than just textual documentation. If you need a protocol, you're better off using a formal protocol.

When a subclass implements an informal protocol, it doesn't refer to the original declaration, but declares in its interface which of the methods it will implement and defines the methods in its implementation in the usual way.

1.3.8 Declarations

You can declare Objective-C objects in many different ways. However, the way in which you declare an object has no effect on that object's runtime behavior. Rather, the way that you declare an object controls how the compiler checks your program for type safety.

1.3.8.1 Dynamic typing

Use the id type to declare a pointer to an unspecified kind of object. This is called dynamic typing. For example:

id  obj ;

With this declaration, obj can be a pointer to an object of any type. An id has the following compile-time properties:

• You can send any kind of message to an id. (The compiler will warn you if the method name is unknown or ambiguous; see Section 1.3.5.4.) If at runtime the object does not have an appropriate method or delegate (see Section 1.11), a runtime error will occur (see Section 1.8).

• You can assign any other object to an id.

• You can assign an id to any object. The compiler will not remind you that this can be dangerous. Using an id in this way means you assume the risk of assigning an object to an incompatible variable.

1.3.8.2 Static typing

In Objective-C, any deviation from fully dynamic typing is called static typing. With static typing you instruct the compiler about the types of values you intend variables to have. All static typing is done within the inheritance relation: where a variable's class or protocol is declared, a value from a descendant class or protocol is always acceptable.

You can use static typing in three ways, shown in the following examples:

MyClass* obj

Declares obj to be an instance of MyClass or one of its descendants. This is called static typing. Declaring obj this way has the following compile-time effects:

• You can assign obj to any variable of type id.

• You can assign any variable of type id to obj.

• You can assign obj to any variable whose declared type is MyClass or one of its ancestors.

• You can assign to obj any variable whose declared type is MyClass or one of its descendants.

• The compiler will warn you if you assign obj or assign to it in a way not covered in the previous cases. A cast will quiet the compiler but will not prevent an incompatible assignment at runtime.

• You can send to obj any message that MyClass or one of its parent classes declares.

id < ProtocolList> obj

Does not constrain the class of obj, but declares that it conforms to the specified protocols. The protocol list consists of protocol names separated by commas. This declaration has the following compile-time effects:

• You can assign obj to an object that does not conform to the protocol.

• Assigning obj an object that is not declared to conform will trigger a compiler warning.

• Sending to obj a message not included in the protocol will trigger a compiler warning.

MyClass < ProtocolList>* obj

Declares that obj is an instance of MyClass or one of its descendants, and that it conforms to the listed protocols. The compile-time effects of this declaration are the combination of the effects of the preceding two styles of declaration.

Due to a compiler bug, gcc does not always correctly use the declared protocol for type checking.

1.3.8.3 Type qualifiers

Type qualifiers go before a C or Objective-C type in a method declaration, and modify that type. Supported qualifiers are:

in		oneway

out		bycopy

inout		byref

These qualifiers can only be used in formal protocols and implementations, not in class or category declarations. They specify how parameters are to be passed when you are using remote messaging. Type qualifiers can be combined, although not all combinations make sense. They are discussed at greater length in Section 1.6 .

1.3.9 Predefined Types, Constants, and Variables

Objective-C adds the special type id, which is generic like a void* in C++, but which does not preclude you from sending messages. In addition, the Objective-C environment provides some C types, constants, and variables to support object-oriented programming.

1.3.9.1 Types

Along with class types that you define, Objective-C introduces these built-in types you can use when declaring variables:

id

A generic Objective-C object pointer type. You can send any message to the variables of this type without compiler warnings. (See Section 1.3.8.) At runtime the receiver may handle the message, delegate it, or explicitly ignore it. If it does none of these, a runtime exception occurs. (See Section 1.8.) Unspecified method return or parameter types default to id.

The name id is a C typedef for a pointer to a structure with one member: a field that points to a class object. Section 1.9 discusses this at greater length.

Class

A pure C type: a pointer to an Objective-C class structure. The runtime system contains a structure for each Objective-C class in your program's code. Calling the -class method of any object returns a value of this type.

MetaClass

Provided in the GNU runtime but not in Darwin, this is identical to Class. It's used for clarity when operating with metaclass objects.

Protocol

An Objective-C class. The runtime system contains an instance for each Objective-C protocol that is either adopted by a class in your program's code or referred to in an @protocol declaration directive. You can construct a Protocol instance from its name using the @protocol directive with a parameter.

BOOL

A logical type whose variables have two possible values: YES and NO. The name BOOL is a typedef for the C type char.

SEL

A unique specifier for a method selector. Often implemented as a pointer to the method's name, but you should treat it as an opaque handle. You can construct a selector from a method name using the @selector directive.

IMP

A pointer to the implementation of a method that returns an id. More precisely, an IMP is defined this way:

typedef id (*IMP)(id, SEL, ...)

The first two parameters are the receiver and selector values that are passed to any method; the remaining variable-length argument list holds the method's visible parameters.

You can construct an IMP from a message selector using methods of the root classes Object or NSObject. Calling a method through its IMP is considerably faster than using regular dispatch, but may not work correctly if the method does not return an id. Section 1.15 gives an example.

1.3.9.2 Constants

The following constants are all defined as preprocessor symbols:

nil

A value describing an uninitialized or invalid id. Defined to be zero.

Nil

A value describing an uninitialized or invalid Class variable. Defined to be zero.

YES

A value of BOOL type, describing a true state. Defined to be one.

NO

A value of BOOL type, describing a false state. Defined to be zero.

1.3.9.3 Variables

These are special variables, set up for you by the Objective-C runtime:

self

Inside an instance method, this variable refers to the receiver of the message that invoked the method.

super

Not really a variable, but it looks enough like one to be included in this list. Inside a method, if you send a message to super, method dispatch will start looking in the parent class of the method's class. That is, super represents the static parent, not the parent at runtime.

_cmd

A variable of type SEL, available inside any Objective-C method, and describing the selector of the method.

isa

This is a protected field of all Objective-C objects. You do have access to it, although it's better to get it from the class method:

Class C = obj->isa;     // Discouraged.
Class C = [obj class];  // Better.

isa points to the class object representing the object's class.