Static Options

Objective-C objects are dynamic entities. As many decisions about them as possible are pushed from compile time to run time:

• The memory for objects is dynamically allocated at run time by class methods that create new instances.
• Objects are dynamically typed. In source code (at compile time), any object pointer can be of type id no matter what the object's class. The exact class of an id variable (and therefore its particular methods and data structure) isn't determined until the program is running.
• Messages and methods are dynamically bound, as described under "How Messaging Works" in the previous chapter. A run-time procedure matches the method selector in the message to a method implementation that "belongs to" the receiver.

These features give object-oriented programs a great deal of flexibility and power, but there's a price to pay. Messages are somewhat slower than function calls, for example, (though not much slower due to the efficiency of the run-time system) and the compiler can't check the exact types (classes) of id variables.

To permit better compile-time type checking, and to make code more self-documenting, Objective-C allows objects to be statically typed with a class name rather than generically typed as id. It also lets you turn some of its object-oriented features off in order to shift operations from run time back to compile time.

Static Typing

If a pointer to a class name is used in place of id in an object declaration,

Rectangle *thisObject;

the compiler restricts the value of the declared variable to be either an instance of the class named in the declaration or an instance of a class that inherits from the named class. In the example above, thisObject can only be a Rectangle of some kind.

Statically typed objects have the same internal data structures as objects declared to be ids. The type doesn't affect the object; it affects only the amount of information given to the compiler about the object and the amount of information available to those reading the source code.

Static typing also doesn't affect how the object is treated at run time. Statically typed objects are dynamically allocated by the same class methods that create instances of type id. If Square is a subclass of Rectangle, the following code would still produce an object with all the instance variables of a Square, not just those of a Rectangle:

Rectangle *thisObject = [[Square alloc] init];

Messages sent to statically typed objects are dynamically bound, just as objects typed id are. The exact type of a statically typed receiver is still determined at run time as part of the messaging process. A display message sent to thisObject

[thisObject display];

will perform the version of the method defined in the Square class, not its Rectangle superclass.

By giving the compiler more information about an object, static typing opens up possibilities that are absent for objects typed id:

• In certain situations, it allows for compile-time type checking.
• It can free objects from the restriction that identically named methods must have identical return and argument types.
• It permits you to use the structure pointer operator to directly access an object's instance variables.

The first two topics are discussed in the sections below. The third was covered in the previous chapter under "Defining a Class" .

Type Checking

With the additional information provided by static typing, the compiler can deliver better type-checking services in two situations:

• When a message is sent to a statically typed receiver, the compiler can check to be sure that the receiver can respond. A warning is issued if the receiver doesn't have access to the method named in the message.
• When a statically typed object is assigned to a statically typed variable, the compiler can check to be sure that the types are compatible. A warning is issued if they're not.

An assignment can be made without warning provided the class of the object being assigned is identical to, or inherits from, the class of the variable receiving the assignment. This is illustrated in the example below.

Shape     *aShape;
Rectangle *aRect;

aRect = [[Rectangle alloc] init];
aShape = aRect;

Here aRect can be assigned to aShape because a Rectangle is a kind of Shape-the Rectangle class inherits from Shape. However, if the roles of the two variables are reversed and aShape is assigned to aRect, the compiler will generate a warning; not every Shape is a Rectangle. (For reference, see Figure 3-2 in the previous chapter that shows the class hierarchy including Shape and Rectangle.)

There's no check when the expression on either side of the assignment operator is an id. A statically typed object can be freely assigned to an id, or an id to a statically typed object. Because methods like alloc and init return ids, the compiler doesn't check to be sure that a compatible object is returned to a statically typed variable. The following code is error-prone, but is allowed nonetheless:

Rectangle *aRect;
aRect = [[Shape alloc] init];

Return and Argument Types

In general, methods that share the same selector (the same name) must also share the same return and argument types. This constraint is imposed by dynamic binding. Because the class of a message receiver, and therefore class-specific details about the method it's asked to perform, can't be known at compile time, the compiler must treat all methods with the same name alike. When it prepares information on method return and argument types for the run-time system, it creates just one method description for each method selector.

However, when a message is sent to a statically typed object, the class of the receiver is known by the compiler. The compiler has access to class-specific information about the methods. Therefore, the message is freed from the restrictions on its return and argument types.

Static Typing to an Inherited Class

An instance can be statically typed to its own class or to any class that it inherits from. All instances, for example, can be statically typed as NSObjects.

However, the compiler understands the class of a statically typed object only from the class name in the type designation, and it does its type checking accordingly. Typing an instance to an inherited class can therefore result in discrepancies between what the compiler thinks would happen at run time and what will actually happen.

For example, if you statically type a Rectangle instance as a Shape,

Shape *myRect = [[Rectangle alloc] init];

the compiler will treat it as a Shape. If you send the object a message to perform a Rectangle method,

BOOL solid = [myRect isFilled];

the compiler will complain. The isFilled method is defined in the Rectangle class, not in Shape.

However, if you send it a message to perform a method that the Shape class knows about,

[myRect display];

the compiler won't complain, even though Rectangle overrides the method. At run time, Rectangle's version of the method will be performed.

Similarly, suppose that the Upper class declares a worry method that returns a double,

- (double)worry;

and the Middle subclass of Upper overrides the method and declares a new return type:

- (int)worry;

If an instance is statically typed to the Upper class, the compiler will think that its worry method returns a double, and if an instance is typed to the Middle class, it will think that worry returns an int. Errors will obviously result if a Middle instance is typed to the Upper class. The compiler will inform the run-time system that a worry message sent to the object will return a double, but at run time it will actually return an int and generate an error.

Static typing can free identically named methods from the restriction that they must have identical return and argument types, but it can do so reliably only if the methods are declared in different branches of the class hierarchy.

Getting a Method Address

The only way to circumvent dynamic binding is to get the address of a method and call it directly as if it were a function. This might be appropriate on the rare occasions when a particular method will be performed many times in succession and you want to avoid the overhead of messaging each time the method is performed.

With a method defined in the NSObject class, methodForSelector:, you can ask for a pointer to the procedure that implements a method, then use the pointer to call the procedure. The pointer that methodForSelector: returns must be carefully cast to the proper function type. Both return and argument types should be included in the cast.

The example below shows how the procedure that implements the setFilled: method might be called:

void (*setter)(id, SEL, BOOL);
int i;

setter = (void (*)(id, SEL, BOOL))[target
    methodForSelector:@selector(setFilled:)];
for ( i = 0; i < 1000, i++ )
    setter(targetList[i], @selector(setFilled:), YES);

The first two arguments passed to the procedure are the receiving object (self) and the method selector (_cmd). These arguments are hidden in method syntax but must be made explicit when the method is called as a function.

Using methodForSelector: to circumvent dynamic binding saves most of the time required by messaging. However, the savings will be significant only where a particular message will be repeated many times, as in the for loop shown above.

Note that methodForSelector: is provided by the Cocoa run-time system; it's not a feature of the Objective-C language itself.

Getting an Object Data Structure

A fundamental tenet of object-oriented programming is that the data structure of an object is private to the object. Information stored there can be accessed only through messages sent to the object. Although it is generally considered a poor programming practice, there is a way to strip an object data structure of its "objectness" and treat it like any other C structure. This makes all the object's instance variables publicly available.

When given a class name as an argument, the @defs() directive produces the declaration list for an instance of the class. This list is useful only in declaring structures, so @defs() can appear only in the body of a structure declaration. This code, for example, declares a structure that would be identical to the template for an instance of the Worker class:

struct workerDef {
    @defs(Worker)
} *public;

Here public is declared as a pointer to a structure that's essentially indistinguishable from a Worker instance. With a little help from a type cast, a Worker id can be assigned to the pointer. The object's instance variables can then be accessed publicly through the pointer:

id aWorker;
aWorker = [[Worker alloc] init];

public = (struct workerDef *)aWorker;
public->boss = nil;

This technique of turning an object into a structure makes all of its instance variables public, no matter whether they were declared @private, @protected, or @public.

Objects generally aren't designed with the expectation that they'll be turned into C structures. You may want to use @defs() for classes you define entirely yourself, but it should not be applied to classes found in a framework or to classes you define that inherit from framework classes.

© 2001 Apple Computer, Inc.