Complete code: https://github.com/minbi/ambiguous-swift
Is there a way to disambiguate use of an ObjC method from Swift 3?
I need to make the modification in ObjC so that the usage in Swift is as seamless as possible.
Objective C bridged to Swift
#interface A
+ (instancetype)singletonA;
#end
#interface B: A
+ (instancetype)singletonB;
#end
Usage in Swift 3.
I don't understand why this would be ambiguous. Doesn't the fact that I call the method from B "disambiguate the usage even a little?
var b: B! = B.singleton()
Error
Ambiguous use of 'singleton()'
Apparently this is a known bug. Swift does not handle overriding methods or properties well.
"Ambiguous use of 'propertyName'" error given overridden property with didSet observer
Related
I've read along here and here about conforming to Swift protocols in Objective-C headers, and I'm not quite getting the behaviour I want - I'm also looking for a better understanding of how this all works. Here's my scenario.
I have a protocol in Swift:
PersonalDetailsProtocol.swift
#objc
protocol PersonalDetailsProtocol {
func doSomeWork()
}
I then have an Objective-C class with a header and implementation file
RegistrationPersonalDetails.h
#protocol PersonalDetailsProtocol; // Forward declare my Swift protocol
#interface RegistrationPersonalDetails : NSObject <PersonalDetailsProtocol>
#end
RegistrationPersonalDetails.m
#import "RegistrationPersonalDetails.h"
#implementation RegistrationPersonalDetails
- (void)doSomeWork {
NSLog(#"Working...");
}
#end
At this point everything compiles, although there is a warning in the RegistrationPersonalDetails.h file stating Cannot find protocol definition for 'PersonalDetailsProtocol'. Other than that warning, the issue I'm facing is I can't publicly call the doSomeWork method on an instance of RegistrationPersonalDetails.
The call site in Swift would look something like:
let personalDetails = RegistrationPersonalDetails()
personalDetails.doSomeWork()
but I get an error stating:
Value of type 'RegistrationPersonalDetails' has no member 'doSomeWork'
I get that the method isn't public, because it's not declared in the header file. But I didn't think it should have to be as long as the protocol conformance is public i.e. declared in the header file.
Can anyone point me on the right path here and offer an explanation? Or is this even possible? I can obviously rewrite the protocol in ObjC, but I just always try to add new code as Swift.
In pure objective-c, you cannot make a class conform to a protocol without importing it in the header. To make the use of a protocol private, the conformance shouldn't be declared in the header. It remains possible to call such a method using a cast however, but it should be done with caution because it's a little bit unsafe :
if ([anInstance respondToSelector:#selector(myProtocolMethod)])
[(id<MyProtocol>)anInstance myProtocolMethod];
I'm not familiar with Swift, but I think you can do the same this way (or something close to it) :
if let conformingInstance = anInstance as? MyProtocol
conformingInstance.myProtocolMethod
EDIT : To complete my first assertion, forward declarations can still be used in the header when you need to declare a method receiving or returning an instance conforming to that protocol :
#SomeProtocol;
// This is not possible
#interface MyClass : NSObject <SomeProtocol>
// But this is possible
#property (nonatomic) id<SomeProtocol> someProperty;
-(void) someMethod:(id<SomeProtocol>)object;
#end
In this document Apple clearly said that :
Forward declarations of Swift classes and protocols can be used only
as types for method and property declarations.
So it seems that the rule is the same whatever the protocol is an Objective-c protocol or a Swift protocol.
I am trying to make use of an Objective-C API in Swift. I can only seem to call the shareMyInstance() method from Swift, and not the initOpenApi() method for some reason. I'm not sure if there is some sort of scope identifier present in the interface, but I can't make use of initOpenApi, even though both are in the header. I also cannot see the method bodies, but I don't believe that affects the scope of the function.
This is locking me into using Objective-C, because for some reason I can access all of the functions from Objective-C, but only 3 of the 4 from Swift.
Header file (LCOpenSDK_Api.h):
#ifndef LCOpenSDK_LCOpenSDK_Api_h
#define LCOpenSDK_LCOpenSDK_Api_h
#import <Foundation/Foundation.h>
#interface LCOpenSDK_Api: NSObject
+ (LCOpenSDK_Api*) shareMyInstance;
- (id) initOpenApi:(NSString*)addr port:(NSInteger)port CA_PATH:(NSString*)caPath;
- (NSInteger)request:(void*)req resp:(void*)resp timeout:(NSInteger)timeout;
- (void)uninitOpenApi;
#end
#endif
My code (.swift):
import Foundation
#objc(LeChangePlayerView)
class LeChangePlayerView: UIView {
//...
#objc
override init(frame: CGRect) {
super.init(frame: frame)
var lc = LCOpenSDK_Api.shareMyInstance()!; //Fine
//Need this function!
lc.initOpenApi("openapi.easy4ip.com", 443, "") //Value of type 'LCOpenSDK_Api' has no member 'initOpenApi'
}
The only possible other explanation is that there is a different header file with the same name, but different interface, but this is highly unlikely because shareMyInstance, request and unitOpenApi are all available, and going to the definition from within the swift file using Xcode points to the same file. It is a dynamic framework, and as of right now, I can only view the headers, not the method implementations. I'm not sure if there's a solution to this, but this is another problem I could use help with. Could they have locked the original source code somehow, as well as made that specific method private?
Although initOpenApi is an instance method, Swift recognises it as an initialiser as it starts with the word init. Initialisers are translated from Objective-C into Swift-style initialisers.
In Objective-C you would say something like [[LCOpenSDK_Api alloc] initOpenAPI:#"openapi.easy4ip.com", port: 443, CA_PATH: #""]
In Swift the word init is stripped and there is no need to explicitly allocate a new instance:
let lc = LC_OpenSDK_Api(openApi:"openapi.easy4ip.com:, port: 443, CA_PATH:"")
However, you need to refer to the documentation from the framework to determine if you want to access the singleton instance LC_OpenSDK_Api.shareMyInstance or whether you want to create a specific instance as I showed above.
I have a Go interface
type GetResponse interface { OnResult(json string) }
I have to subscribe on that event OnResult from ObjC using this interface.
func Subscribe( response GetResponse){ response.OnResult("some json") }
ObjC bind gives me a corresponding protocol and a basic class
#interface GetResponse : NSObject <goSeqRefInterface, GetResponse> {
}
#property(strong, readonly) id _ref;
- (instancetype)initWithRef:(id)ref;
- (void)onResult:(NSString*)json;
#end
So, I need to get this json in my ObjC env. How can I do that?
Subclassing If I subclass this GetResponse or just use it as is and pass to Subscribe routine, it crashes
'go_seq_go_to_refnum on objective-c objects is not permitted'
Category if I create struct on Go side with the protocol support, I can't subclass it but at least it's not crashes:
type GetResponseStruct struct{}
func (GetResponseStruct) OnResult(json string){log.Info("GO RESULT")}
func CreateGetResponse() *GetResponseStruct{ return &GetResponseStruct{}}
I have a solid object without obvious way to hook up my callback. If I make a category and override the onResult routine, it's not called. Just because overriding existing methods of class is not determined behavior according to AppleDoc. Anytime OnResult called from Go, the default implementation invokes and "GO RESULT" appears.
Swizzling I tried to use category and swizzle (replace method's implementation with mine renamed method) but it only works if I call onResult from ObjC env.
Any way to solve my issue? Or I just red the doc not very accurately? Please help me
I ran into a similar issue today. I thought it was a bug in gomobile but it was my misunderstanding of swift/objc after all. https://github.com/golang/go/issues/35003
The TLDR of that bug is that you must subclass the protocol, and not the interface. If you are using swift then you can subclass the GetResponseProtocol:
class MyResponse: GetResponseProtocol
If in objc, then you probably want to directly implement the GetResponse protocol, rather than subclassing the interface.
I have a class defined in Objective-C, whose initializer is -initWithError: (the initializer can fail due to a dependence on an outside resource). I want this to bridge into Swift as init() throws. The regular initializer inherited from NSObject, -init, can be marked unavailable, as I don't want it to be used.
In Objective-C, I have:
#interface Foo : NSObject
- (instancetype _Nullable)initWithError:(NSError **)error;
#end
This works fine in Objective-C, of course.
In Swift, -initWithError gets bridged as init(error: ()) throws. This is presumably because removing withError: from the method name results in init() which conflicts with the inherited plain -init initializer. This can be called from Swift like so:
let foo = try Foo(error: ())
This is strange looking, as the error parameter is void. It would certainly be better if this were imported as init() throws. The obvious solution is to mark -init using NS_UNAVAILABLE in the Objective-C header. Unfortunately, this doesn't work. -initWithError: still gets bridged as init(error: ()), and trying to call try Foo() results in a compiler error saying that init() is unavailable in Swift.
Is there a more elegant solution to this so that try init() just works?
You can rename the function using NS_SWIFT_NAME. In this case:
- (instancetype _Nullable)initWithError:(NSError **)error NS_SWIFT_NAME(init());
That said, this feels like a compiler bug. I'd suggest opening a defect.
Working on a mixed framework. imported inside the Obj-C file but the internal classes are not visible, only the public ones.
The documentation clearly states the internal clasees should be available between Swift and Obj-C:
Importing Swift into Objective-C To import a set of Swift files in the same framework target as your Objective-C code, you don’t
need to import anything into the umbrella header for the framework.
Instead, import the Xcode-generated header file for your Swift code
into any Objective-C .m file you want to use your Swift code from.
Because the generated header for a framework target is part of the
framework’s public interface, only declarations marked with the public
modifier appear in the generated header for a framework target. You
can still use Swift methods and properties that are marked with the
internal modifier from within the Objective-C part of your framework,
as long they are declared within a class that inherits from an
Objective-C class. For more information on access-level modifiers, see
Access Control in The Swift Programming Language (Swift 2).
Code Sample (Create a new project with a framework)
// SwiftObject.swift
public class SwiftObject: NSObject {
public class func doSomething() {}
}
internal class YetAnotherSwiftObject: NSObject {
internal class func doSomething() {}
}
// SomeObject.m file
#implementation SomeObject
- (void)someMethod {
[SwiftObject doSomething];
}
- (void)someOtherMethod {
[YetAnotherSwiftObject doSomething]; // Use of undeclared identifier
}
#end
As indicated in the docs, declarations marked with internal modifier don't appear in the generated header, so the compiler does not know about them and thus complaints. Of course, you could send messages using performSelector approach, but that's not convenient and bug-prone. We just need to help the compiler know that those declarations are there.
First, we need to use #objc attribute variant that allows you to specify name for your symbol in Objective-C:
// SwiftObject.swift
#objc(SWIFTYetAnotherSwiftObject)
internal class YetAnotherSwiftObject: NSObject {
internal class func doSomething() {}
}
And then you just need to create #interface declaration with the methods you want to use in your code - so the compiler will be happy, and also apply SWIFT_CLASS macro with the symbol name you've specified earlier - so the linker would pick the actual implementation:
// SomeObject.m file
SWIFT_CLASS("SWIFTYetAnotherSwiftObject")
#interface YetAnotherSwiftObject : NSObject
+ (void)doSomething;
#end
#implementation SomeObject
- (void)someOtherMethod {
[YetAnotherSwiftObject doSomething]; // Should work now !!!
}
#end
I've used the interface declaration in .m file just for clarity, the better option would be to combine such declarations in .h file, and include it.
By declaring methods in that interface we're making a promise to compiler, and it won't complain if you'll put there a method that does not exist (or with wrong signature, etc.) Obviously, you'll crash in runtime in that case - so be cautious.
For me it just worked by checking: "Allow app extension API only". You find it by going to the project setting, select your target and then it is in the General tab under Deployment Info.
Can someone explain to me, why this does solve the problem?
While the above solution works (https://stackoverflow.com/a/33159964/5945317), it seems overly complicated and unintuitive:
Complicated, because it seems to add more things than necessary – I will provide a smoother solution below.
Unintuitive, because the objc macro SWIFT_CLASS resolves to SWIFT_RUNTIME_NAME, and the provided value is not actually the runtime name – nor is the objc class name in the header matching the Swift attribute param in #objc. Still, surprisingly, the solution works – but to me it is not clear why.
Here is what we have tested in our own project, and believe to be the better solution (using the example above):
// YetAnotherSwiftObject.swift
#objc(OBJCPREFIXYetAnotherSwiftObject)
internal class YetAnotherSwiftObject: NSObject {
#objc internal class func doSomething() {}
}
// OBJCPREFIXYetAnotherSwiftObject.h
#interface OBJCPREFIXYetAnotherSwiftObject : NSObject
+ (void)doSomething;
#end
That's it. The interface looks like a regular objc interface. This gives the added benefit that you can include it in other header files (which you cannot do if you use the SWIFT_CLASS macro, as it comes from the autogenerated Swift header file, which in turn you cannot include in an objc header, due to circular dependency).
On the Swift side, the only thing relevant is that you provide the class with the proper objc name. Mind that I only used the name prefix for language consistency – you can even just use YetAnotherSwiftObject everywhere (i.e., in the objc header and in the #objc attribute in Swift – but you need to keep this attribute with explicit naming in any case, and need to keep it consistent with the class name in the header).
This also makes your life easier if you're in the process of converting your objc framework step by step to Swift. You just keep the objc header as before, and now provide the implementation in Swift.
Methods and properties that are marked with the internal modifier and declared within a class that inherits from an Objective-C class are accessible to the Objective-C runtime.
so let's make use of that:
class MyInternalClass: NSObject {
#objc var internalProperty = 42
}
#interface MyPublicClass()
#end
#implementation MyPublicClass
+ (void) printValue {
Class myInternalClass = NSClassFromString(#"MyPackageNameIfAny.MyInternalClass");
id myInternalClassInstance = [myInternalClass new];
int value = [myInternalClassInstance performSelector:#selector(internalProperty)];
NSLog(#"Value is %d ", value); // "value is 42"
}
#end
Using the SWIFT_CLASS macro and #objc class attribute could easily lead to errors when archiving. This approach is safer.