我最近一直在学习Swift。
我决定编写一个混合的Swift / Objective-C应用程序,该应用程序使用两种语言实现的相同算法来完成计算密集型任务。
该程序将计算大量的质数。
我定义了一个计算对象的Swift版本和Objective-C版本都应该符合的协议。
这些对象都是单例,因此我在Objective-C中创建了一个典型的单例访问方法:
+ (NSObject <CalcPrimesProtocol> *) sharedInstance;
整个协议如下所示:
#import <Foundation/Foundation.h>
@class ComputeRecord;
typedef void (^updateDisplayBlock)(void);
typedef void (^calcPrimesCompletionBlock)(void);
@protocol CalcPrimesProtocol <NSObject>
- (void) calcPrimesWithComputeRecord: (ComputeRecord *) aComputeRecord
withUpdateDisplayBlock: (updateDisplayBlock) theUpdateDisplayBlock
andCompletionBlock: (calcPrimesCompletionBlock) theCalcPrimesCompletionBlock;
@optional //Without this @optional line, the build fails.
+ (NSObject <CalcPrimesProtocol> *) sharedInstance;
@end
该类的Objective-C版本完全实现上述定义的方法,无需担心。
快速版本有一种方法:
class func sharedInstance() -> CalcPrimesProtocol
但是,如果将该方法作为协议的必需方法,则会出现编译器错误“类型” CalcPrimesSwift不符合协议“ CalcPrimesProtocol”。
但是,如果我在协议中将单例类方法sharedInstance标记为可选,则它可以工作,并且可以在Swift类或Objective-C类上调用该方法。
我在Swift类方法的定义中是否错过了一些微妙之处?鉴于我能够在Swift类或Objective-C类上调用sharedInstance()类方法,因此这似乎不太可能。
您可以从Github下载该项目,然后查看是否需要。它称为SwiftPerformanceBenchmark。(链接)
在Objective-C中,我们总是在传递指针,而指针始终可以是nil
。Objective-C的程序员很多利用的事实,将消息发送给nil
什么也没做,返回0
/ nil
/ NO
。Swift的处理方式nil
完全不同。对象要么存在(从不nil
),要么不知道它们是否存在(这是Swift可选对象起作用的地方)。
因此,在Xcode 6.3之前,这意味着任何使用Objective-C代码的Swift代码都必须将所有对象引用视为Swift可选对象。关于Objective-C的语言规则,没有什么能阻止对象指针的存在nil
。
这对于使用Swift的Objective-C协议,类等意味着什么呢?我们必须选择非完美的解决方案。
给定以下Objective-C协议:
@protocol ObjCProtocol <NSObject>
@required + (id<ObjCProtocol>)classMethod;
@required - (id<ObjCProtocol>)instanceMethod;
@required - (void)methodWithArgs:(NSObject *)args;
@end
我们可以接受方法定义为包含隐式解包的可选内容:
class MyClass: NSObject, ObjCProtocol {
func methodWithArgs(args: NSObject!) {
// do stuff with args
}
}
这样可以使生成的代码更整洁(我们永远不必在体内解包),但是,我们始终会面临“发现nil,同时解开可选内容”错误的风险。
或者,我们可以将方法定义为真正的可选方法:
class MyClass: NSObject, ObjCProtocol {
func methodWithArgs(args: NSObject?) {
// unwrap do stuff with args
}
}
但这给我们留下了很多混乱的代码。
Xcode 6.3解决了此问题,并为Objective-C代码添加了“可空性注释”。
新引入的两个关键字是nullable
和nonnull
。它们在为Objective-C代码声明返回类型或参数类型的地方使用。
- (void)methodThatTakesNullableOrOptionalTypeParameter:(nullable NSObject *)parameter;
- (void)methodThatTakesNonnullNonOptionalTypeParameter:(nonnull NSObject *)parameter;
- (nullable NSObject *)methodReturningNullableOptionalValue;
- (nonnull NSObject *)methodReturningNonNullNonOptionalValue;
除了这两个注释关键字之外,Xcode 6.3还引入了一组宏,这些宏使将Objective-C代码的大部分内容标记为容易nonnull
(完全不带注释的文件被假定为nullable
)。为此,我们NS_ASSUME_NONNULL_BEGIN
在本节的顶部和NS_ASSUME_NONNULL_END
我们要标记的底部使用。
因此,例如,我们可以将整个协议包装在该宏对中。
NS_ASSUME_NONNULL_BEGIN
@protocol CalcPrimesProtocol <NSObject>
- (void) calcPrimesWithComputeRecord: (ComputeRecord *) aComputeRecord
withUpdateDisplayBlock: (updateDisplayBlock) theUpdateDisplayBlock
andCompletionBlock: (calcPrimesCompletionBlock) theCalcPrimesCompletionBlock;
+ (id <CalcPrimesProtocol> ) sharedInstance;
@end
NS_ASSUME_NONNULL_END
这与将所有指针参数和返回类型标记为效果相同nonnull
(有一些例外,如Apple的Swift博客中的此项记为)。
符合Objective-C协议的Swift类必须将该协议中的所有Objective-C类型都视为可选。
为了弄清楚这一点,我创建了以下Objective-C协议:
@protocol ObjCProtocol <NSObject>
@required + (id<ObjCProtocol>)classMethod;
@required - (id<ObjCProtocol>)instanceMethod;
@required - (void)methodWithArgs:(NSObject *)args;
@end
然后,创建一个Swift类,该类继承自NSObject
并且声明自己与this兼容ObjCProtocol
。
然后,我继续键入这些方法名称,并让Swift为我自动完成方法,这就是我所得到的(我放入方法主体中,其余的则为自动完成):
class ASwiftClass : NSObject, ObjCProtocol {
class func classMethod() -> ObjCProtocol! {
return nil
}
func instanceMethod() -> ObjCProtocol! {
return nil
}
func methodWithArgs(args: NSObject!) {
// do stuff
}
}
现在,如果需要,我们可以使用常规的可选选项(带有?
)来代替这些自动解包的可选选项。编译器对这两者都很满意。关键是,尽管我们必须考虑使用的可能性nil
,因为Objective-C协议无法阻止nil
通过。
如果此协议是在Swift中实现的,我们将选择返回类型是否为可选,而Swift将阻止我们返回nil
未定义非可选返回类型的方法。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句