// Associates an Objective-C id with the specified value on the Lua stack. // As of Lua v5.1.0, all Lua values can be associated with ObjC values; prior // to v5.1.0 this function will only associate ObjC ids with tables. Objective-C is the primary programming language you use when writing software for OS X and iOS. It’s a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime. Welcome to the objective-c community. Is a journal of the overlooked bits in Objective-C, Swift, and Cocoa.

In the real world, people on official business are often required to follow strict procedures when dealing with certain situations. Law enforcement officials, for example, are required to “follow protocol” when making enquiries or collecting evidence.

In the world of object-oriented programming, it’s important to be able to define a set of behavior that is expected of an object in a given situation. As an example, a table view expects to be able to communicate with a data source object in order to find out what it is required to display. This means that the data source must respond to a specific set of messages that the table view might send.

The data source could be an instance of any class, such as a view controller (a subclass of NSViewController on OS X or UIViewController on iOS) or a dedicated data source class that perhaps just inherits from NSObject. In order for the table view to know whether an object is suitable as a data source, it’s important to be able to declare that the object implements the necessary methods.

Objective-C allows you to define protocols, which declare the methods expected to be used for a particular situation. This chapter describes the syntax to define a formal protocol, and explains how to mark a class interface as conforming to a protocol, which means that the class must implement the required methods.

Protocols Define Messaging Contracts

A class interface declares the methods and properties associated with that class. A protocol, by contrast, is used to declare methods and properties that are independent of any specific class.

The basic syntax to define a protocol looks like this:

Protocols can include declarations for both instance methods and class methods, as well as properties.

As an example, consider a custom view class that is used to display a pie chart, as shown in Figure 5-1.

To make the view as reusable as possible, all decisions about the information should be left to another object, a data source. This means that multiple instances of the same view class could display different information just by communicating with different sources.

The minimum information needed by the pie chart view includes the number of segments, the relative size of each segment, and the title of each segment. The pie chart’s data source protocol, therefore, might look like this:

Note: This protocol uses the NSUInteger value for unsigned integer scalar values. This type is discussed in more detail in the next chapter.

The pie chart view class interface would need a property to keep track of the data source object. This object could be of any class, so the basic property type will be id. The only thing that is known about the object is that it conforms to the relevant protocol.

The syntax to declare the data source property for the view would look like this:

Objective-C uses angle brackets to indicate conformance to a protocol. This example declares a weak property for a generic object pointer that conforms to the XYZPieChartViewDataSource protocol.

Note: Delegate and data source properties are usually marked as weak for the object graph management reasons described earlier, in Avoid Strong Reference Cycles.

By specifying the required protocol conformance on the property, you’ll get a compiler warning if you attempt to set the property to an object that doesn’t conform to the protocol, even though the basic property class type is generic. It doesn’t matter whether the object is an instance of UIViewController or NSObject. All that matters is that it conforms to the protocol, which means the pie chart view knows it can request the information it needs.

Protocols Can Have Optional Methods

By default, all methods declared in a protocol are required methods. This means that any class that conforms to the protocol must implement those methods.

It’s also possible to specify optional methods in a protocol. These are methods that a class can implement only if it needs to.

As an example, you might decide that the titles on the pie chart should be optional. If the data source object doesn’t implement the titleForSegmentAtIndex:, no titles should be shown in the view.

You can mark protocol methods as optional using the @optional directive, like this:

In this case, only the titleForSegmentAtIndex: method is marked optional. The previous methods have no directive, so are assumed to be required.

The @optional directive applies to any methods that follow it, either until the end of the protocol definition, or until another directive is encountered, such as @required. You might add further methods to the protocol like this:

This example defines a protocol with three required methods and two optional methods.

Check that Optional Methods Are Implemented at Runtime

If a method in a protocol is marked as optional, you must check whether an object implements that method before attempting to call it.

As an example, the pie chart view might test for the segment title method like this:

The respondsToSelector: method uses a selector, which refers to the identifier for a method after compilation. You can provide the correct identifier by using the @selector() directive and specifying the name of the method.

If the data source in this example implements the method, the title is used; otherwise, the title remains nil.

Remember: Local object variables are automatically initialized to nil.

If you attempt to call the respondsToSelector: method on an id conforming to the protocol as it’s defined above, you’ll get a compiler error that there’s no known instance method for it. Once you qualify an id with a protocol, all static type-checking comes back; you’ll get an error if you try to call any method that isn’t defined in the specified protocol. One way to avoid the compiler error is to set the custom protocol to adopt the NSObject protocol.

Protocols Inherit from Other Protocols

In the same way that an Objective-C class can inherit from a superclass, you can also specify that one protocol conforms to another.

As an example, it’s best practice to define your protocols to conform to the NSObject protocol (some of the NSObject behavior is split from its class interface into a separate protocol; the NSObject class adopts the NSObject protocol).

By indicating that your own protocol conforms to the NSObject protocol, you’re indicating that any object that adopts the custom protocol will also provide implementations for each of the NSObject protocol methods. Because you’re presumably using some subclass of NSObject, you don’t need to worry about providing your own implementations for these NSObject methods. The protocol adoption is useful, however, for situations like that described above.

To specify that one protocol conforms to another, you provide the name of the other protocol in angle brackets, like this:

In this example, any object that adopts MyProtocol also effectively adopts all the methods declared in the NSObject protocol.

Conforming to Protocols

The syntax to indicate that a class adopts a protocol again uses angle brackets, like this

This means that any instance of MyClass will respond not only to the methods declared specifically in the interface, but that MyClass also provides implementations for the required methods in MyProtocol. There’s no need to redeclare the protocol methods in the class interface—the adoption of the protocol is sufficient.

Note: The compiler does not automatically synthesize properties declared in adopted protocols.

If you need a class to adopt multiple proto

Lua 5.1 In Objective C