To create an object, you send an alloc message to a class. In response, that class creates an object in memory and gives you a pointer to it. Creating an object looks like this:

N​S​M​u​t​a​b​l​e​A​r​r​a​y​ ​*​a​r​r​a​y​I​n​s​t​a​n​c​e​ ​=​ ​[​N​S​M​u​t​a​b​l​e​A​r​r​a​y​ ​a​l​l​o​c​]​;​

Here an instance of type NSMutableArray is created, and you are returned a pointer to it in the variable arrayInstance. When you have a pointer to an instance, you can send messages to it. The first message you always send to a newly allocated instance is an initialization message. Although sending an alloc message to a class creates an instance, the instance isn’t valid until it has been initialized.

[​a​r​r​a​y​I​n​s​t​a​n​c​e​ ​i​n​i​t​]​;​

Because an object must be allocated and initialized before it can be used, we always combine these two messages in one line.

N​S​M​u​t​a​b​l​e​A​r​r​a​y​ ​*​a​r​r​a​y​I​n​s​t​a​n​c​e​ ​=​ ​[​[​N​S​M​u​t​a​b​l​e​A​r​r​a​y​ ​a​l​l​o​c​]​ ​i​n​i​t​]​;​

The code to the right of the assignment operator (=) says, “Create an instance of NSMutableArray and send it the message init.” Both alloc and init return a pointer to the newly created object so that you have a reference to it. (A pointer holds the location of an object in memory, not the object itself. It “points to” the object.) Typically, you use the assignment operator to store the pointer in a variable.

Combining two messages in a single line of code is called a nested message send. The innermost brackets are evaluated first, so the message alloc is sent to the class NSMutableArray first. This returns a new, uninitialized instance of NSMutableArray that is then sent the message init.

What do you do with an instance that has been initialized? You send it more messages.

Let’s take a closer look at message anatomy. First of all, a message is always contained in square brackets. Within a pair of square brackets, a message has three parts:

One such message you can send an NSMutableArray instance is addObject:

[​a​r​r​a​y​I​n​s​t​a​n​c​e​ ​a​d​d​O​b​j​e​c​t​:​a​n​o​t​h​e​r​O​b​j​e​c​t​]​;​

Sending the addObject: message to arrayInstance (the receiver) triggers the addObject: method (named by the selector) and passes in anotherObject (an argument).

The addObject: message has only one argument, but Objective-C methods can take a number of arguments or none at all. The message init, for instance, has no arguments.

Another message you can send an NSMutableArray instance is replaceObjectsInRange:​withObjectsFromArray:​range:. This message takes three arguments. Each argument is paired with a label in the selector, and each label ends with a colon. The selector is all of the labels taken together (Figure 2.2).

Figure 2.2  Parts of a message send

This pairing of labels and arguments is an important feature of Objective-C. In other languages, this method would look like this:

a​r​r​a​y​I​n​s​t​a​n​c​e​.​r​e​p​l​a​c​e​O​b​j​e​c​t​s​I​n​R​a​n​g​e​W​i​t​h​O​b​j​e​c​t​s​F​r​o​m​A​r​r​a​y​R​a​n​g​e​(​a​R​a​n​g​e​,​
 ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​a​n​o​t​h​e​r​A​r​r​a​y​,​
 ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​a​n​o​t​h​e​r​R​a​n​g​e​)​;​

In these languages, it isn’t completely obvious what each of the arguments sent to this function are. In Objective-C, however, each argument is paired with the appropriate label.

[​a​r​r​a​y​I​n​s​t​a​n​c​e​ ​r​e​p​l​a​c​e​O​b​j​e​c​t​s​I​n​R​a​n​g​e​:​a​R​a​n​g​e​
 ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​w​i​t​h​O​b​j​e​c​t​s​F​r​o​m​A​r​r​a​y​:​a​n​o​t​h​e​r​A​r​r​a​y​
 ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​r​a​n​g​e​:​a​n​o​t​h​e​r​R​a​n​g​e​]​;​

It takes some getting used to, but eventually, Objective-C programmers appreciate the clarity of arguments being interposed into the selector. The trick is to remember that for every pair of square brackets, there is only one message being sent. Even though replaceObjectsInRange:​withObjectsFromArray:​range: has three labels, it is still only one message, and sending that message results in only one method being executed.

Notice the distinction being made between a message and a method: a method is a chunk of code that can be executed and a message is the act of asking a class or object to execute a method. However, the name of a message always matches the name of the method to be executed.

In Objective-C, the name of a method is what makes it unique. Therefore, a class cannot have two methods with the same name and different types for their arguments or return type. However, two methods can have the same individual labels, as long as the name of each method differs when taken as a whole. For example, the class NSString has two methods rangeOfString:options: and rangeOfString:options:range:.

To destroy an object, you send it the message release.

[​a​r​r​a​y​I​n​s​t​a​n​c​e​ ​r​e​l​e​a​s​e​]​;​

This line of code destroys the object pointed to by the arrayInstance variable. (It’s actually a bit more complicated than that, and you’ll learn about the details of memory management in the next chapter.) It is important to note that although you destroyed the object, the variable arrayInstance still has a value – the address of where the NSMutableArray instance used to exist. If you send a message to arrayInstance now, it will cause a problem because that object no longer exists.

However, if arrayInstance is set to nil, the problem goes away. (nil is the zero pointer. C programmers know it as NULL. Java programmers know it as null.)

a​r​r​a​y​I​n​s​t​a​n​c​e​ ​=​ ​n​i​l​;​

Now there is no danger of sending a message to the outdated memory address. Sending a message to nil is okay in Objective-C – nothing happens. In a language like Java, sending messages to nil is illegal, so you see this sort of thing a lot:

i​f​ ​(​r​o​v​e​r​ ​!​=​ ​n​i​l​)​ ​{​
 ​ ​ ​ ​[​r​o​v​e​r​ ​d​o​S​o​m​e​t​h​i​n​g​]​;​
}​

In Objective-C, this check is unnecessary because a message sent to nil is ignored. (A corollary: if your program isn’t doing anything when you think it should be doing something, an unexpected nil pointer is often the culprit.)