I have a class that needs to pass a Protocol to an Obj-C function. I have a constructor that takes the Protocol, but as the class is a generic that also takes the same protocol, I thought I could optimise it. However, if I try to use the generic value when calling the function, it fails to compile. I've tried various combinations of ".self" and ".Type" and ".Protocol", both in the code and in the generic argument, and nothing works. Is there any way to achieve this?
This is a Playground project to show the problem.
import Foundation
#objc protocol TestProtocol {
}
class Test<P> {
init() {
test(p: P.self) // Fails to compile with: Cannot convert value of type 'P.Type' to expected argument type 'Protocol'
test(p: TestProtocol.self) // Compiles
}
func test(p: Protocol) {
}
}
let c = Test<TestProtocol>()
Related
In kotlin Declaraing extensions as members, what does it mean "the dispatch of such functions is virtual with regard to the dispatch receiver type, but static with regard to the extension receiver type."
Is this mean that "the extension function doesn't follows its reciever's class type. It follows parameter type(?in this code call method parameter)."
please give your warmhearted and generous advice
open class Base { }
class Derived : Base() { }
open class BaseCaller {
open fun Base.printFunctionInfo() {
println("Base extension function in BaseCaller")
}
open fun Derived.printFunctionInfo() {
println("Derived extension function in BaseCaller")
}
fun call(b: Base) {
b.printFunctionInfo() // call the extension function
}
}
class DerivedCaller: BaseCaller() {
override fun Base.printFunctionInfo() {
println("Base extension function in DerivedCaller")
}
override fun Derived.printFunctionInfo() {
println("Derived extension function in DerivedCaller")
}
}
fun main() {
BaseCaller().call(Base()) // "Base extension function in BaseCaller"
DerivedCaller().call(Base()) // "Base extension function in DerivedCaller" - dispatch receiver is resolved virtually
DerivedCaller().call(Derived()) // "Base extension function in DerivedCaller" - extension receiver is resolved statically
}
Since you have linked the documentation, I take it that you have read the following part
The instance of the class in which the extension is declared is called
dispatch receiver, and the instance of the receiver type of the extension method is called extension receiver.
After you have understood the above terminology, you need to understand following points
If you don't know about virtual methods read this
Extensions are resolved statically. Consider the following code block
fun call(b: Base) {
// This will always call extension function defined on the Base class
// even if you pass an object of Derived class
b.printFunctionInfo() // call the extension function
}
// This calls the printFunctionInfo defined on the Base, even though we pass Derived
DerivedCaller().call(Derived())
Now to your question
the dispatch of such functions is virtual with regard to the dispatch
receiver type, but static with regard to the extension receiver type.
With the Extensions are resolved statically point we have established that no matter which object you pass (Base or Derived) the call function will always invoke an extension function defined on the Base type.
But which extension function will be invoked? one in the Base class or the one in Derived class ?
This depends on the type of object which invokes the call function, if you invoke the call with an Object of Base then the extension in the base class will be invoked and if you use the Derived object then the extension in Derived class will be invoked.
I am looking at the Swift code of the ThemeKit theming library.
In particular I would like to understand the following code in NSColor+ThemeKit.swift:
// ThemeKit.set() replacement to use theme-aware color
#objc public func themeKitSet() {
// call original .set() function
themeKitSet()
// check if the user provides an alternative color
if ThemeManager.shared.isEnabled && isThemeOverriden {
// call ThemeColor.set() function
ThemeColor.color(with: Selector(colorNameComponent)).set()
}
}
There is what appears to be an endless recursive call, but presumably can't be, since the code works fine. This is confirmed by setting a breakpoint on the call to themeKitSet(). It is not possible to step into the call and execution continues without recursion.
Earlier in the file there is the following call:
swizzleInstanceMethod(cls: NSClassFromString("NSDynamicSystemColor"), selector: #selector(set), withSelector: #selector(themeKitSet))
With the implementation in NSObject+ThemeKit.swift as follows:
/// Swizzle instance methods.
#objc internal class func swizzleInstanceMethod(cls: AnyClass?, selector originalSelector: Selector, withSelector swizzledSelector: Selector) {
guard cls != nil else {
print("Unable to swizzle \(originalSelector): dynamic system color override will not be available.")
return
}
// methods
let originalMethod = class_getInstanceMethod(cls, originalSelector)
let swizzledMethod = class_getInstanceMethod(cls, swizzledSelector)
// add new method
let didAddMethod = class_addMethod(cls, originalSelector, method_getImplementation(swizzledMethod!), method_getTypeEncoding(swizzledMethod!))
// switch implementations
if didAddMethod {
class_replaceMethod(cls, swizzledSelector, method_getImplementation(originalMethod!), method_getTypeEncoding(originalMethod!))
} else {
method_exchangeImplementations(originalMethod!, swizzledMethod!)
}
}
I suspect this is responsible for the magic, but my limited understanding of both Swift and Objective-C is letting me down.
What is happening here? Why is the apparently recursive call not actually recursive?
You correctly identified the magic bit: it's called method swizzling, and it's a way of wholesale replacing an existing method implementation.
You'll see this seemingly-recursive pattern a lot when method swizzling: that themeKitSet call actually runs the original implementation, as the comment says. It's because swizzling swaps the implementations of two methods, in this case themeKitSet and NSDynamicSystemColor.set.
Therefore, post-swizzle, NSDynamicSystemColor.set runs the code you see there, and themeKitSet has become the original implementation.
I would like to implement custom conversion function of my class Foo to be able to pass it to the function that requres Bar object.
Equivalent C++ construction https://en.cppreference.com/w/cpp/language/cast_operator
class Foo {
operator Bar () {...}
}
Kotlin does not have implicit conversions, as an intentional design decision. You would need to make it explicit. You can do this either putting the burden on the caller, or on the receiver.
For example, if I had:
class One()
class Two()
object Utilities {
fun foo(one: One) {
...
}
}
If I want to pass an instance of Two to foo() I would either:
// add extension function for explicit conversion:
fun Two.toOne(): One { ... convert my instance to other type }
// now caller must convert:
Utilities.foo(myTwo.toOne())
The burden above is on the caller to convert, given this new extension function to do the conversion. This is typical of how Kotlin handles everything in the standard library.
But maybe you want to make it feel more implicit, so you could also add:
// add an extension to the callee, for implicit conversion:
fun Utilities.foo(two: Two) { foo(two.toOne()) }
// now caller doesn't have to convert:
Utilities.foo(myTwo)
Now the caller never sees the conversion, although they have to import your extension function and their IDE hopefully will auto-suggest this for them. So it feels implicit but they had to choose to use that extension, which is easy to do.
Notice that none of the extension functions above needed any modifications to the actual classes. These extensions can be imported individually or in the whole package import. They can be done independently from classes you do or do not control. They can be done from anywhere at any time.
Final code, in its entirety:
// original classes
class One()
class Two()
object Utilities {
fun foo(one: One) {
...
}
}
// extensions
fun Two.toOne(): One {
// ... convert my instance to other type
}
fun Utilities.foo(two: Two) { foo(two.toOne()) }
And now you can use either model as your code style desires.
I am trying to extend Objective C class in my Swift class. This is where I got so far:
SINMessageClientDelegate is Objective C class. ViewController is written in Swift. I already have Bridging Header, so I can use Objective C object in my Swift class.
This is how my Swift code class definition looks like:
class ViewController: UIViewController, SINMessageClientDelegate {
I am getting the following error:
Type "ViewController does not conform to protocol SINMessageClientDelegate"
This is how definition of SINMessageClientDelegate looks like:
#protocol SINMessageClientDelegate <NSObject>
- (void)messageClient:(id<SINMessageClient>)messageClient didReceiveIncomingMessage:(id<SINMessage>)message;
- (void)messageSent:(id<SINMessage>)message recipientId:(NSString *)recipientId;
- (void)messageDelivered:(id<SINMessageDeliveryInfo>)info;
- (void)messageFailed:(id<SINMessage>)message info:(id<SINMessageFailureInfo>)messageFailureInfo;
I tried to create these methods using Swift in ViewController:
// Tells the delegate that a message has been received.
func messageClient(id: SINMessageClient, didReceiveIncomingMessage:SINMessage)
{
}
// Tells the delegate that a message for a specific recipient has been sent by the local user.
func messageSent(id: SINMessage, recipientId: NSString)
{
}
// Tells the delegate that a message has been delivered (to a particular recipient).
func messageDelivered(id: SINMessageDeliveryInfo)
{
}
func messageFailed(id: SINMessage, info: SINMessageFailureInfo)
{
}
Can someone advice what is the proper way of doing this, since I am getting the same error after adding my code?
Thanks!
One problem in the way you pose your question is that you're using the wrong words. You are not "extending a class". You are conforming to (or adopting) a protocol.
The trouble, however, is that you are not adopting it (conforming to it), as the error message rightly tells you. The reason apparently is that you don't know how to read Objective-C. You'll need to learn to do that in order to proceed. For example, given this Objective-C declaration:
- (void)messageClient:(id<SINMessageClient>)messageClient
didReceiveIncomingMessage:(id<SINMessage>)message;
The Swift implementation will need to be:
func messageClient(SINMessageClient,
didReceiveIncomingMessage message: SINMessage) { /* ... */ }
Whereas what you have is not at all the same thing. You have this:
func messageClient(id: SINMessageClient,
didReceiveIncomingMessage:SINMessage) { /* ... */ }
That is not a match, so you are not implementing the required method, but rather some totally different method. That's legal, but it has nothing to do with the protocol you are supposed to be conforming to. And the same for the rest of your declarations.
It may be that this is actually not possible currently, which would be unfortunate. I'm trying to call the CoreMIDI API to set up a MIDI input. This is what I'm trying to do in Swift:
var midiClient = MIDIClientRef()
var inputPort = MIDIEndpointRef()
var status: OSStatus
func readProc(packetList: UnsafePointer<MIDIPacketList>, readProcRefCon: UnsafeMutablePointer<Void>, srcConnRefCon: UnsafeMutablePointer<Void>) -> Void {
}
status = MIDIClientCreate("MIDI client", nil, nil, &midiClient);
status = MIDIDestinationCreate(midiClient, "MIDI input", readProc, nil, &inputPort);
But I get this error: '(UnsafePointer, UnsafeMutablePointer, UnsafeMutablePointer) -> Void' is not convertible to 'MIDIReadProc'
MIDIReadProc's typedef is the following:
typealias MIDIReadProc = CFunctionPointer<((UnsafePointer<MIDIPacketList>, UnsafeMutablePointer<Void>, UnsafeMutablePointer<Void>) -> Void)>
Is there a way to get a function pointer for my readProc method to pass to the MIDIDestinationCreate API?
In Swift 2.0 (as part of Xcode 7), C APIs that deal in function pointers use function types that are annotated #convention(c). You can pass any Swift function, method, or closure as a #convention(c) function type — but only if that closure conforms to C conventions... e.g. it can't capture state from its surrounding scope.
For details, see Type Attributes in The Swift Programming Language.
As for what's in Xcode 6: Swift 1.x doesn't have a way to convert a Swift function or closure to a C function pointer -- the sole use of the CFunctionPointer type is to pass function pointers imported from (Obj)C APIs to other (Obj)C APIs.
You can declare a function pointer in C code that you expose to Swift via your project's bridging header, then use Swift to pass that to CoreMIDI. But since you're going to be reaching across a bridge anyway, you might instead think about which parts of your project are best to keep in C and what the best interface is from those parts to your Swift code is.
Swift 1.x (Old Way)
There's a way to do that - Objective-C Runtime is the trick.
import CoreMIDI
let block : #objc_block
(UnsafePointer<MIDIPacketList>,
UnsafeMutablePointer<Void>,
UnsafeMutablePointer<Void>) -> Void =
{ (pktlist,readProcRefCon,srcConnRefCon) in
//Your code goes here...
}
let imp : COpaquePointer =
imp_implementationWithBlock(unsafeBitCast(block, AnyObject.self))
let callback : MIDIReadProc = unsafeBitCast(imp, MIDIReadProc.self)
Works with CoreFoundation callbacks.
Should work for CoreMIDI too.
Swift 2.x (New Way)
In Swift 2 the process becomes "less hacky" (and slightly more readable).
import CoreMIDI
let callback : #convention(c) (pktlist : UnsafePointer<MIDIPacketList>,
readProcRefCon : UnsafeMutablePointer<Void>,
srcConnRefCon : UnsafeMutablePointer<Void>) -> Void =
{ (pktlist, readProcRefCon, srcConRefCon) in
}
let usableCallback = unsafeBitCast(callback, MIDIReadProc.self)