Swift Blog RSS: Access Control

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<atom:link href="http://developer.apple.com/swift/blog/news.rss" rel="self" type="application/rss+xml" />
<title>Swift Blog - Apple Developer</title>
<link>http://developer.apple.com/swift/blog/</link>
<description>Get the latest news and helpful tips on the Swift programming language from the engineers who created it.</description>
<language>en-US</language>
<lastBuildDate>Wed, 23 Jul 2014 14:00:00 PDT</lastBuildDate>
<generator>Custom</generator>
<copyright>Copyright 2014, Apple Inc.</copyright>

<item>
<title>Access Control</title>
<link>http://developer.apple.com/swift/blog/?id=5</link>
<guid>http://developer.apple.com/swift/blog/?id=5</guid>
<description> In Xcode 6 beta 4, Swift adds support for access control. This gives you complete control over what part of the code is accessible within a single file, available across your project, or made public as API for anyone that imports your framework. The three access levels included in this release are:      private  entities are available only from within the source file where they are defined.    internal  entities are available to the entire module that includes the definition (e.g. an app or framework target).    public  entities are intended for use as API, and can be accessed by any file that imports the module, e.g. as a framework used in several of your projects.     By default, most entities have  internal  access. This allows application developers to largely ignore access control, and most Swift code already written will continue to work without change. Your framework code does need to be updated to define  public  API, giving you total control of the exposed interface your framework provides.   The  private  access level is the most restrictive, and makes it easy to hide implementation details from other source files. By properly structuring your code, you can safely use features like extensions and top-level functions without exposing that code to the rest of your project.   Developers building frameworks to be used across their projects need to mark their API as  public . While distribution and use of 3rd-party binary frameworks is not recommended (as mentioned in a previous blog post), Swift supports construction and distribution of frameworks in source form.   In addition to allowing access specification for an entire declaration, Swift allows the  get  of a property to be more accessible than its  set . Here is an example class that is part of a framework:  [view code in blog]  When mixing Objective-C and Swift, because the generated header for a framework is part of the framework’s public Objective-C interface, only declarations marked  public  appear in the generated header for a Swift framework. For applications, the generated header contains both  public  and  internal  declarations.    For more information,  The Swift Programming Language  and  Using Swift with Cocoa and Objective-C  books have been updated to cover access control.  Read the complete Xcode 6 beta 4 release notes here . </description>
<pubDate>Wed, 23 Jul 2014 14:00:00 PDT</pubDate>
<content:encoded><![CDATA[ In Xcode 6 beta 4, Swift adds support for access control. This gives you complete control over what part of the code is accessible within a single file, available across your project, or made public as API for anyone that imports your framework. The three access levels included in this release are:      private  entities are available only from within the source file where they are defined.    internal  entities are available to the entire module that includes the definition (e.g. an app or framework target).    public  entities are intended for use as API, and can be accessed by any file that imports the module, e.g. as a framework used in several of your projects.     By default, most entities have  internal  access. This allows application developers to largely ignore access control, and most Swift code already written will continue to work without change. Your framework code does need to be updated to define  public  API, giving you total control of the exposed interface your framework provides.   The  private  access level is the most restrictive, and makes it easy to hide implementation details from other source files. By properly structuring your code, you can safely use features like extensions and top-level functions without exposing that code to the rest of your project.   Developers building frameworks to be used across their projects need to mark their API as  public . While distribution and use of 3rd-party binary frameworks is not recommended (as mentioned in a previous blog post), Swift supports construction and distribution of frameworks in source form.   In addition to allowing access specification for an entire declaration, Swift allows the  get  of a property to be more accessible than its  set . Here is an example class that is part of a framework:  [view code in blog]  When mixing Objective-C and Swift, because the generated header for a framework is part of the framework’s public Objective-C interface, only declarations marked  public  appear in the generated header for a Swift framework. For applications, the generated header contains both  public  and  internal  declarations.    For more information,  The Swift Programming Language  and  Using Swift with Cocoa and Objective-C  books have been updated to cover access control.  Read the complete Xcode 6 beta 4 release notes here . ]]></content:encoded>
</item>

[other items snipped]

</channel>
</rss>