If you have not been exposed to permission control before, let’s listen to a short story:
Xiao Ming is a freshman at Wudaokou Institute of Technology. He has been a little worried recently because he often uses his hot water kettle in his room, as if it is from his own family, but due to the affection of his classmates, he is embarrassed to say it. Until one day, he and his senior sister Xiao K complained.
After hearing this, the senior sister said: In college collective life, most of the things are shared by roommates. If you don't want others to take it, I can help you seal it. As long as you put the private mark, they won't see your things, and they won't use your things anymore.
Xiao Ming said, "Damn you, senior sister, you can still know magic...
Starting from the Xcode 6 beta 5 version, Swift has added support for Access Control. In fact, the permission control is the same as Xiao Ming’s items. You can set whether the kettle can be used by yourself, only people in the dormitory can be used by you, or the whole school can be used by you.
From then on, you can completely control the "confidentiality level" of your code blocks like Director SHIELD, which can only be cited in this file, and which can be used throughout the project. You can also use the spirit of love and open source it into an API that everyone can use as long as it is imported into your framework.
These three permissions are:
#####private private
Use it wherever you write it. Whether it is a class, variable, constant or function, once marked as private, it can only be used in the source file that defines them, and cannot be used for other files.
#####internal
A code block marked internal is accessible within the entire application (App bundle) or framework.
#####public public
Code blocks marked as public are generally used to establish APIs, which is the most open permission, so that anyone can access and use as long as they import this module.
If you want to add a deadline to all love, oh no, it is to mark all code blocks with permissions, it would be strange if you don't feel tired. Fortunately, the default permissions of all code entities in swift are the most commonly used internals. So when you develop your own app, you may not have to worry about permission control at all.
But when you need to write a public API, you must use the public tag "invisible to it" to the code blocks inside, or it cannot be used by others.
Private (private level) has the most stringent permissions, and it can be used to hide the details of certain functions. By structuring your code reasonably, you can safely use extension and advanced features without exposing them to other files in your project.
In addition to setting permissions for the entire declaration, Swift also allows everyone to set the value permissions of a certain property more open than the assignment permissions when needed.
#####For example:
public class ListItem {
//The ListItem class has two public properties
public var text: String
public var isComplete: Bool
// The following code means setting the assignment permission of the variable UUID to private, which can be read for the entire app, but the value can only be written in this file.
private(set) var UUID: NSUUID
public init(text: String, completed: Bool, UUID: NSUUID) {
= text
= completed
= UUID
}
// This section does not have special tag permissions, so it belongs to the default internal level. Available within the framework target, but not for other targets
func refreshIdentity() {
= NSUUID()
}
public override func isEqual(object: AnyObject?) -> Bool {
if let item = object as? ListItem {
return ==
}
return false
}
}
When we use Objective-C and Swift to develop, we need to pay attention to:
●If you are writing an application, Xcode will generate a header file to ensure the interaccessibility of the two, and the generated header file will contain public and internal levels of declarations.
●If your final product is a Swift framework, only declarations marked as public level will appear in the header file. (Because the framework's header file is part of the public Objective-C interface, only the public part is available for Objective-C.)
Although Swift does not recommend that you spread and use third-party frameworks, it is supported for establishing and sharing frameworks in the form of source files. For developers who need to write frameworks that are convenient for applications and multiple projects, remember to mark the API as public level.
If you want to know more about permission control, you can check out Apple's latest official guide to "The Swift Language" and "Using Swift with Cocoa and Objective-C".
These two guides can be downloaded and updated in iBooks.