Home > Articles > Programming > General Programming/Other Languages

  • Print
  • + Share This
This chapter is from the book

Swift and Objective-C

Although you will write your classes in Swift, the classes in the Cocoa frameworks are written in Objective-C. Swift was designed to work seamlessly with Objective-C classes. While you can write Cocoa apps in pure Swift, without a line of Objective-C, it is important to have a basic understanding of how Objective-C works.

Objective-C methods (which are only available on classes, not structures) are not called like functions or like Swift methods. Instead of calling a method on an object, Objective-C sends the object a message.

A message consists of a receiver, selector, and any parameters. The selector is the name of the method you want executed. The receiver is the object that you want to execute that method. Here is an example of sending a message in Objective-C:

NSString *newString;
newString = [originalString stringByReplacingOccurrencesOfString: @"Mavericks"
                                                      withString: @"Yosemite"];

In this example, the receiver is originalString, an instance of NSString, and the selector is stringByReplacingOccurrencesOfString:withString:. The parameters are the two NSString literals.

Note that the selector in the message is “the name of the method.” It is not the method itself or even a reference to it. You can think of a selector as a glorified string.

Objective-C classes know how to receive a message, match the selector with a method of the same name, and execute the method. Or they can do something else with the selector, like forward it in a message to another class. Relying on selectors and message-passing is relatively unique among languages in modern use, and its dynamic nature made the powerful design patterns of Cocoa, and later iOS, possible.

Calling a method is a cut-and-dried process. Either the object implements the method or it does not, and this can be determined at compile time. Passing a message, on the other hand, is dynamic. At runtime, the object is asked, “Does your class implement a method with this name?” If yes, the method with that name is executed. If no, the message is run up the inheritance hierarchy: The superclass is asked, “Do you have a method with this name?” If that class does not have the method, then its superclass is asked, and so on. If the message reaches NSObject at the top of the hierarchy, and NSObject says, “No, I do not have a method with that name,” then an exception occurs, and your app will halt.

You are developing in Swift, which means that you are not writing message sends in code; you are calling methods. These Swift methods have to be named in such a way that the Swift compiler can turn a method call into a message send when the receiver is an Objective-C object.

If you were to write the above message send in Swift, it would look like this:

let newString = originalString.stringByReplacingOccurrencesOfString("Mavericks"
                                                        withString: "Yosemite")

Remember, the Swift method has two parameters in the parameter list, but only one has a name. This is why you see methods named in this text and in Apple’s documentation with underscores where you expect a parameter name. For example, this method is listed as stringByReplacingOccurrencesOfString(_:withString:).

  • + Share This
  • 🔖 Save To Your Account