Understanding SEL and @Selector


#1

I understand that the delegate implements all required methods of the protocol and those optional methods it is interested in. Because a delegate may not have implemented a particular optional method there needs to be a way to test whether or not a particular method is implemented. What I am not sure about is the methodology for making this test. Can anyone provide more details on what is happening when CLLocationManager’s finishedFindingLocation: has the following statement:

SEL updateMethod = @selector(locationManager:didUpdateToLocation:fromLocation:);

Are we essentially wrapping the name of the method in a function that will turn it into its complied signature so that we can see whether or not it was implemented? It would be great to get more background on this topic. It is introduced in the book rather quickly and I am not exactly sure what is happening behind the scenes.

Thanks


#2

[quote=“srbjwe”]SEL updateMethod = @selector(locationManager:didUpdateToLocation:fromLocation:);

Are we essentially wrapping the name of the method in a function that will turn it into its complied signature so that we can see whether or not it was implemented?[/quote]

SEL represents a method name, but in a form the compiler can understand (the compiler assigns a signature to methods instead of going by name).

You pass a SEL - which is returned from @selector() - to callbacks/delegates to call a particular method at runtime.