Could you briefly explain what @objc
and dynamic
mean in Swift 4 using Xcode 9.x?
With tries and errors and following articles in the stackoverflow, I have eventually achieved this snippet to work. But I would like to know a little bit about those magical keywords.
class SampleViewController: NSViewController {
@objc class Parameters : NSObject {
@objc dynamic var value1: Double = 0 // bound to Value of a NSTextfield with NumberFormatter
@objc dynamic var value2: Double = 0 // as "parameters.value1" for the Model Key Path
}
@objc dynamic var parameters = Parameters()
@objc dynamic var value3: Double { // in the similar way as "value3" for the Model Key Path
get {
return parameters.value1 + parameters.value2
}
}
override class func keyPathsForValuesAffectingValue(forKey key: String) -> Set<String> {
switch key {
case "value3" :
return Set(["parameters.value1", "parameters.value2"])
default:
return super.keyPathsForValuesAffectingValue(forKey: key)
}
}
}
Swift generates code that is only readable to other Swift code. But if we need to interact with the Objective-C runtime, we need to instruct Swift what to do. Here comes @objc to make swift code available to Objective-C.
dynamic is a declaration modifier that you can apply to either function or variable declarations. It can only be used within a class and it tells the compiler to use dynamic dispatch over static dispatch.
The dynamic keyword is used to declare dynamic types. The dynamic types tell the compiler that the object is defined as dynamic and skip type-checking at compiler time; delay type-checking until runtime. All syntaxes are checked and errors are thrown at runtime.
Use Selectors to Arrange Calls to Objective-C Methods In Objective-C, a selector is a type that refers to the name of an Objective-C method. In Swift, Objective-C selectors are represented by the Selector structure, and you create them using the #selector expression.
The @objc attribute makes your Swift API available in Objective-C and the Objective-C runtime. A Swift class or protocol must be marked with the @objc attribute to be accessible and usable in Objective-C. This attribute tells the compiler that this piece of Swift code can be accessed from Objective-C.
If your Swift class is a descendant of an Objective-C class, the compiler automatically adds the @objc attribute for you. By default Swift generates code that is only available to other Swift code, but if you need to interact with the Objective-C runtime – all of UIKit, for example – you need to tell Swift what to do.
There are two keywords to keep in mind when dealing with interoperability: @objc means you want your Swift code (class, method, property, etc.) to be visible from Objective-C. dynamic means you want to use Objective-C dynamic dispatch. The state of the world circa 2015.
@objc means you want your Swift code (class, method, property, etc.) to be visible from Objective-C. dynamic means you want to use Objective-C dynamic dispatch. The state of the world circa 2015. The slightly confusing bit for me was that this scheme conflates the concepts of visibility and dispatch. In Swift 3...
Having fun with Xcode and its disassembler, I have found some. Thanks to Mike Henderson's comment.
Firstly, adding a @objc
modifier seems to have the compiler write its corresponding symbol name in a __OBJC
segment of executables and/or library files, which will be then used by the Objective-C run-time system.
otool -o filename
command shows us the contents of __OBJC
segment.
Secondly, adding a dynamic
modifier seems to have the compiler insert additional assembler codes to interact with the Objective-C run-time system. The additional code realizes that accessing dynamic properties will be done through objc_msgSend()
and its related functions. Similarly, calling dynamic
methods also will be done through objc_msgSend()
.
Now, in my understandings, the jargon dynamic dispatch
implies use of objc_msgSend()
while static dispatch
does no use of it. In the latter case, both accessing variables and calling functions will be done without intervention of the Objective-C run-time system, which is in the similar, but not exactly same, way of C++ ABI.
Apparently, static one is faster than dynamic one. But static one is incapable of Objective-C's magical benefits, though. With the programming language Swift, we have opportunities to utilize both aspects by choosing either static or dynamic dispatch depending on the situation, by omitting or adding those magical keywords, respectively.
Thanks!
Further readings:
@objc means you want your Swift code (class, method, property, etc.) to be visible from Objective-C.
dynamic means you want to use Objective-C dynamic dispatch.
Swift 3 - dynamic vs @objc
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With