Daily Archives: October 12, 2010

Objective C

Objective-C is the primary language used to write Mac software. If you’re comfortable with basic object-oriented concepts and the C language, Objective-C will make a lot of sense.

Objective-C is a thin layer on top of C, and moreover is a strict superset of C; it is possible to compile any C program with an Objective-C compiler, and to freely include C code within an Objective-C class.

Objective-C derives its object syntax from Smalltalk. All of the syntax for non-object-oriented operations (including primitive variables, preprocessing, expressions, function declarations, and function calls) are identical to that of C, while the syntax for object-oriented features is an implementation of Smalltalk-style messaging.

The id Variable Type

The variable type that is added by Objective C is id. It is the default type for objects in Objective C. Think of this as a special variable type (which is actually a pointer to a special data structure – namely the object)

All objects can refer to themselves by using the label self. This is necessary if, in the code that defines the object, the programmer wants to make the object execute one of its methods. For example, suppose an object has a method called updateRecords. If a command

[self updateRecords];

is received, then the updateRecords command will be executed, presumably to cause the updating of instance variables.

All objects can refer to superclass by the name super. For example:

[super updateRecords]

Interface File: Declaration of a Class

If you look in a directory where some Objective C Swarm code resides, you will see files in pairs, such as ObserverSwarm.h and ObserverSwarm.m, ModelSwarm.h and ModelSwarm.m, and so forth. The “h” files are the interface files (commonly called header files), while the “m” files are the implementation files

Figure 3-1. Objective C Basics 

As illustrated in Figure 3-1, the interface declares the name of the class and the name of its superclass. Then it gives a list of variable types and names enclosed by braces ({}), and then the names of the methods that the class can implement are listed. The variables defined in this list can be used by any of the methods defined for the class. (These are often called “ivars”, short for instance variables.)

Example 3-1. Objective C class 

(1)@interface Bug(2) : SwarmObject(3)
  int xPos, yPos;
  int worldXSize, worldYSize;(4)
  id foodSpace;

- setX: (int) x Y: (int) y;(5)
- step;(6)
- (return_type)look: (direction_type) d;(7)

(1) Declarations of instance variables and methods
(2) Sub class
(3) Super class
(4) Instance Variables
(5) declares method called set that takes two arguments
(6) declares a method called step.
(7) declares a method called look that takes one argument of type direction_type and returns an argument of type return_type.

Implementation File: Defining a Class

Each implementation file–the .m that parallels the .h — must import its header file. For the header file described above, called Bug.h, for example, the implementation looks like:

#import "Bug.h"
@implementation  Bug
- setX: (int) x Y: (int) y
 xPos = x;
 yPos = y;
 return self;
- step
 // body
 return self;

- (return_type)look: (direction_type)d
  return_type returnval;
  // body of method
  return returnval;

This example shows a number of important features. First, note that the method look specifies a return type, (return_type). In this example, return_type would have to be replaced by a variable type, such asintfloat, or whatever, and returnval would have to be a variable of that type. When that method is called, the receiving code must be able to accept a return of that type. In contrast, the method step does not specify a return type. That means the default type, id, is returned. The code that calls this method must be consistent with that return type.

The return self command is used for two types of situations. Suppose the method is not intended to create any output, but rather it changes some instance variables. For example, suppose there is some program that creates an instance of Bug called aBug. Then that object is sent this message:

[aBug step]

In such a case, the code that calls that method does not expect anything back from it (except itself). Rather than fuss with void as the return type, as one might in C, one can simply return self.

In another case, one might actually intend to return the object to a list or another object. In such a case, return self will also be appropriate. If one is making a list of collected bugs, for example, then the usage ofreturn self in that method will give back aBug id to the calling program. To be perfectly concrete about it, suppose the calling code has a list called collectedBugs. Then using the addLast notation from the Swarm collections library, the command to add aBug to the list after being collected might look like this:

[collectedBugs addLast: [aBug look:
%d bloggers like this: